1451818 - Firefox Nightly on Linux seems to have changed the JavaScript keyboard events you get from typing Ctrl+Shift+E in a textarea

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Chris Siebenmann]

I use the addon Textern on my Linux machines (64-bit Fedora 27). By default it's activated with Ctrl+Shift+E in textareas. This activation works in Firefox 59.0.1 and in the current Firefox Developer edition ('6.0b10') but no longer works in Firefox Nightly, apparently because of a change in what keyboard events are generated here.

Textern implements its keyboard activation with a content script that adds a keydown listener and then attempts to analyze and match the key events against its configured shortcut. Instrumenting Textern's source shows that in Firefox Nightly, Ctrl+Shift+E ends up generating a final a keydown event with a keyCode of 229 and a KeyboardEvent.key value that console.log() renders as 'Process' (although .code reports as 'KeyA'). isComposing is also reported as 'true' for the duration.

(Since isComposing is true, this may be a change to Linux composing keys behavior. If so, it may be unintended and it's certainly surprising and not compatible with how Firefox behaves now.)

In Firefox Developer edition, the same Ctrl+Shift+E sequence gives a final keydown event with a keyCode of 69, a .key value of 'E', a .code of 'KeyE', and isComposing is false.

This may be related to bug #1448739, since both involve ctrl-shift-e behavior.

In all versions of Firefox (back to 59.0.2), Ctrl+Shift+E without Textern working appears to invoke some sort of odd behavior (perhaps composing behavior) where the following nine characters will be silently swallowed (for all characters I've tried; it's possible that some sequences produce results).

Comment 1

[Chris Siebenmann]

The Ctrl+Shift+E behavior in textareas on Fedora 27 turns out to be because of a GTK+ 3 feature designed to let you enter emoji, documented here:

    https://developer.gnome.org/gtk3/stable/GtkIMContextSimple.html

Hopefully this doesn't have undesirable interactions with things that Firefox wants to do.

(This behavior will presumably start showing up on other Linuxes and Unixes as the relevant version of GTK+ 3 starts spreading.)

Comment 2

[(no longer active)]

Recent regression, needs an owner.

Comment 3

[Andrew Overholt [:overholt]]

Masayuki, do you know what's up here?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

As comment 1, it must be expected behavior. As far as I know, GTK3's IMContextSimple handles Ctrl+Shift+E and entering emoji mode (sending "preedit_start" and "preedit_change" signals to us). Therefore, the key combination needs to be marked as "processed by IME" for conforming to UI Events. Starting from Firefox 61, we started to take same behavior as the other browsers when IME handles input so that we now set keyCode to 229 and key to "Process".

So, the Textern should change its own shortcut key combination to the others since it's available only Linux but Ctrl+Shift+E is now new GTK's system shortcut key.

Note that as far as I checked GTK 3.22, the shortcut key is hardcorded and cannot disable with settings.