with latest firefox right-click behaves like terminal is "img", specifically, no copy/paste

[fur-hebwiki]

Details

• Browser and browser version: Firefox 72.0.2 (64 bit)
• OS version: windows 10
• xterm.js version: not sure. whatever runs on the demo page ( https://xtermjs.org/ ) as of Feb. 5 2020.

Steps to reproduce

1. fire up firefox, version >= 72.0.2 (tested on windows 10, though i'm pretty sure it behaves the same on mac and linux. did not test on older version of FF)
2. go to demo page https://xtermjs.org/
3. right click inside the terminal

EXPECTED: "normal" context menu (back/forward, copy, paste etc.)

OBSERVED: depending where in the terminal you click, you get either the normal context menu or the image context menu. context menu is very important in terminal, since keyboard shortcut for cut/paste do not work (in any browser, afaik).

this seems to be specific to firefox: at least chrome behaves as expected. i did not test any other browser. Terminal.ts, line 421 (on commit 3d2d35f), says:

// Handle right click context menus
    if (Browser.isFirefox) {
      // Firefox doesn't appear to fire the contextmenu event on right click
      this.register(addDisposableDomListener(this.element, 'mousedown', (event: MouseEvent) => {
        if (event.button === 2) {
          rightClickHandler(event, this.textarea, this.screenElement, this._selectionService, this.options.rightClickSelectsWord);
        }
      }));
    } else {
      this.register(addDisposableDomListener(this.element, 'contextmenu', (event: MouseEvent) => {
        rightClickHandler(event, this.textarea, this.screenElement, this._selectionService, this.options.rightClickSelectsWord);
      }));
    }

the comment says: // Firefox doesn't appear to fire the contextmenu event on right click i assume at some point, firefox did not have context menu for "canvas" elements. apparently, it does now, so probably this code has to change: maybe the "else" now works for FF, so the condition can be changed to something like "is firefox && browser version >= 72" or somesuch.

maybe FF still needs special handling, but the current handling is wrong.

peace.``

[jerch]

@fur-hebwiki Cannot repro under linux with FF 72. I get for any renderer (canvas/DOM/webgl) the right context menu.

Can you check if changing the renderer does affect this?

@Tyriar Were there recent changes to the textarea logic/hack done?

[fur-hebwiki]

thanks for the prompt response.

Cannot repro under linux with FF 72. I get for any renderer (canvas/DOM/webgl) the right context menu.

(i did not know renderer is selectable - i encountered this bug as a user, not as a developer, so the code to create the terminal is not mine. in both sites where i encountered it (the "real" one and xtermjs demo page) use canvas).

some suggestion for reproducing:

1. reproducible easily and repeatedly (though not consistently - see below) on win10. if i'll manage to repro on linux (not next to my linux box ATM), i'll inform you or update the ticket. theoretically, maybe there's a diff between FF 72 and 72.0.2, but it does not sound likely.
2. more importantly: you should right click all over the terminal, repeatedly - the behavior is inconsistent. my guess is that there's some kind of race bendition between the "mousedown" event and the "contextmenu" event, and the result of this race is not consistent. make sure to click inside the "canvas" element - in the demo, some of the visual "terminal" area can be outside the canvas.. i tried to set FF event breakpoint, for mouse events (contextmenu and click, and later for all of them), but FF did not stop anywhere. i may be doing something wrong, or FF is doing something wrong, or "terminal" somehow suppress debugging (i doubt it). chrome happily stops for "contextmenu" and "mousedown".

on further digging, it may not even depend on the point: in the demo, it seems that the terminal can be wider than the canvas: in this case, right-clicking will be "good" in the area outside the canvas, but still, inconsistent behavior: sometimes it's the standard FF context menu, with the icons at top (back/forward/refresh/bookmark), and sometimes it's a "naked" context menu, w/o those icons.

it seems there's a fierce competition going on between the "contxtmenu" event and the "mousedown" event. since the code only handles "mousedown" for firefox, whenever the "contextmenu" event fires first, it is handled by the default handler of "canvas", which is very similar to that of an img. i'm guessing the handler eats up the "mousedown" event in these cases (or not - however, something does, since only one menu is opened per each right-click). this actually may be a new thing, and it also may be specific to win10 - i know nothing about the message pump and how the browser creates events. it is possible that the source of the event (and of the competition) is the OS itself.

tl;dr: right-click around and a lot - as the report states, the behavior is not consistent. i originally thought it depends on the point you click, but on further experiments, even the same point is inconsistent. FF has context menu for canvas for a long time now, so the comment in the code is definitely wrong.

peace

On Wed, Feb 5, 2020 at 5:22 PM jerch [email protected] wrote:

@fur-hebwiki https://github.com/fur-hebwiki Cannot repro under linux with FF 72. I get for any renderer (canvas/DOM/webgl) the right context menu.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xtermjs/xterm.js/issues/2695?email_source=notifications&email_token=AAGJGQTWVD674VLLSEFTGEDRBM33JA5CNFSM4KQS5S6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5GT7Y#issuecomment-582642175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGJGQULMGJT7YYKSY25WD3RBM33JANCNFSM4KQS5S6A .

[jerch]

Tested it with FF 72.0.1.

FF has context menu for canvas for a long time now, so the comment in the code is definitely wrong.

FF is not part of our development tests, so there might be outdated workarounds. Our automated tests run with puppeteer (chromium engine). Not sure if they could be extended to FF somehow. The tests heavily rely on the devtools protocol, I think FF does not support it to a workable extend. Selenium would require a serious rewrite of the tests while providing less testable information, not a viable way for us. So yeah, FF heavily relies on the user side when it comes to testing.

[Tyriar]

Were there recent changes to the textarea logic/hack done?

Not this one https://github.com/xtermjs/xterm.js/pull/2632, that was closed

[nirui]

Encountered the same problem here.

I also discovered a workaround for it: if you add contenteditable="true" to the xterm-cursor-layer element, it should pop the context menu for text editing tool instead. But I don't really know about the implications, so I don't recommend it until after the pros here has actually figured this problem out.

[Tyriar]

Seems fixed, I tested on all renderers:

Firefox 108.0 (64-bit)