Firefox: NS_ERROR_NOT_IMPLEMENTED on unsupported movements in Visual & Caret Mode

[philg-dev]

Regarding the SyntaxError I've mentioned in #4629

I just realized, that Firefox only returns a SyntaxError on completely invalid values for the granularity, which was triggered by vimword in our case before I added the necessary return statements.

In cases where granularity is set to a value that is defined in the method standard, but isn't implemented in Firefox, it throws NS_ERROR_NOT_IMPLEMENTED instead. So those errors still appear in the Firefox console even after my fix from #4632.

Quote from MDN modify#granularity

Note: Firefox does not implement "sentence", "paragraph", "sentenceboundary", "paragraphboundary", or "documentboundary". WebKit and Blink do.

From VisualMode.prototype.movements defined in content_scripts/mode_visual.js

  ")": "forward sentence",
  "(": "backward sentence",
  "}": "forward paragraph",
  "{": "backward paragraph",
  "G": "forward documentboundary",
  "gg": "backward documentboundary"

So Vimium's bindings for ( ) { } gg G currently fail in Firefox and produce the error in the console.

It might be worth considering catching these cases and adding a warning message to inform the user about this incompatibility. However in those cases the HUD is already occupied showing the Visual Mode or Caret Mode respectively, so I don't know how that would work.

Alternatively, we might also go the extra mile and try to find an implementation to polyfill (some of) this missing behavior to become available in Firefox as well. I feel like documentboundary might be fairly easy to implement - paragraph and sentence might be more tricky.

@philc what do you think we should do? I wanted to discuss this first before going down that rabbit hole on my own. The minimum fix, I would suggest to implement is catching these cases to avoid the console errors.

To Reproduce

Steps to reproduce the behavior:

1. Use Vimium on Firefox
2. enter Visual or Caret Mode ('v' or 'v' followed by 'c')
3. use any of the bindings ( ) { } gg G
4. selection / caret doesn't change
5. NS_ERROR_NOT_IMPLEMENTED appears in the browser console

Browser and Vimium version

Firefox 135.0
Vimium 2.1.2

[philc]

Hey @philg-dev, this is interesting analysis.

To summarize, we have these problems and possible solutions when using an unsupported boundary in Firefox:

1. Those motions don't work

• a) Wait and hope that Firefox supports them some day
• b) Try to polyfill

2. The user isn't told about it

• a) Show a temporary message on top of the visual mode indicator, e.g. a flash notification on
  top of or in place of the persistent visual mode notification.

3. The console is spammed with verbose JS errors

• a) Swallow the errors
• b) Swallow, but replace with console.warn messages so it's clear what's happening

If we do nothing else, I prefer we do 3b so at least we have an explicit log of what's happening, to avoid future bug reports about it.

I think 2a would be better than just logging console errors, and is probably straightforward.

If we try to tackle 1, I wouldn't want to introduce a complicated polyfill, but if it's short and clear, I think that's acceptable. I agree that G and gg are the most important of the missing boundaries.

[philg-dev]

@philc yes, your summary nails it.

Note on 1

Just to clarify: the motions don't work specifically in Visual / Caret Mode. In Normal Mode gg and G to scroll around the page works perfectly fine, as it doesn't have anything to do with selection.modify.

on 1 a):

From what I've seen regarding some other features that are kinda niche, Firefox might take years in order to implement the missing functionality.

I found a bugzilla ticket on this topic which has been open since March 2021 with little to no activity developers themselves.

Regrading a fix for Vimium:

At the very first glance I couldn't find an existing polyfill for this and even if it exists, it would probably be quite complicated in total. Therefore, since you prefer not to add a complicated polyfill, we would end up not being able to support the sentence and paragraph movements in Firefox. Thus we would definitely need to handle the errors for those cases, so as a first step I would take a look at implementing 2 a) as you've described to cover all the error cases mentioned above.

In a further step, we could still try to find a short and clear polyfill solution to provide documentBoundary (gg, G) functionality.