1475738 - Fennec and Geckoview do not fire letter or number keypress events while typing into a contenteditable element.

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Keyboards and IME, defect, P2)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: test.html

Fennec and Geckoview do not fire keypress events for letters or numbers while editing contenteditable elements (at least while editing contenteditable content using the on-screen keyboard).

This causes CodeMirror to behave strangely, appearing to delete words one has just entered upon pressing space (as per the related webcompat.com issue).

Geckoview is also affected.

Desktop Firefox and Chrome mobile do fire the events.

I tested this using the attached quick-and-dirty file.

Comment 1

[Mike Taylor [:miketaylr]]

Masayuki, is this a known bug? Thanks.

Comment 2

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

It depends on how Android/IME sends input events. I'm not familiar with Android's native IME nor our IME handler.

As far as I've tested with my Android device, Chrome does not fire keypress events even when I commit only one character with IME. (Probably, we dispatch a set of key events when user inputs only one character.)

jchen?

Comment 3

[(inactive) Jim Chen [:jchen] [:darchons]]

I think we do synthesize keydown/keyup events in that case, but we don't synthesize keypress. There may be a reason why we don't synthesize keypress but I'm not sure what.

Comment 4

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

(In reply to Jim Chen [:jchen] [:darchons] from comment #3)
> I think we do synthesize keydown/keyup events in that case, but we don't
> synthesize keypress. There may be a reason why we don't synthesize keypress
> but I'm not sure what.

keydown/keyup are defined as events representing physical state change of keyboard. keypress is defined as an event inputting a character (i.e., logical). For example, when a key press causes one character composition, keydown should be fired first, then, compositionstart, compositionupdate and compositionend, finally, keyup. However, this breaks the web since a lot of web apps are not aware of composition events. Therefore, for compatibility, browsers may stop using composition events in such case. Then, keydown, keypress and keyup should be fired.

We actually do on Linux (only when composition is only one character) and macOS:
https://searchfox.org/mozilla-central/rev/8384a6519437f5eefbe522196f9ddf5c8b1d3fb4/widget/gtk/IMContextWrapper.cpp#697-699,834,836-837,841,904
https://searchfox.org/mozilla-central/rev/8384a6519437f5eefbe522196f9ddf5c8b1d3fb4/widget/gtk/IMContextWrapper.cpp#1605-1606,1647-1650,1664,1669-1670
https://searchfox.org/mozilla-central/rev/8384a6519437f5eefbe522196f9ddf5c8b1d3fb4/widget/cocoa/TextInputHandler.mm#2308-2309,2420-2422,2426,2473,2484,2497-2499

If Chrome uses a set of key events in some cases which we use a set of composition events, we should do same thing for web-compat.

Comment 5

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 6

[Makoto Kato [:m_kato]]

What IME/keyboard do you use?  At least Chrome/Android doesn't fire keypress with Pixel 2 + GBorad since this issue depends on IME/keyboard

Comment 7

[Thomas Wisniewski [:twisniewski]]

It's the default Samsung keyboard that comes with my Samsung Galaxy S7 Edge phone (which has Android 8.0.0 and Samsung Experience 9.0).

Comment 8

[Makoto Kato [:m_kato]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #7)

It's the default Samsung keyboard that comes with my Samsung Galaxy S7 Edge
phone (which has Android 8.0.0 and Samsung Experience 9.0).

Is this on Samsung Galaxy S7 edge only? How about S8 or S9 (or S7, not edge)?

Comment 9

[Thomas Wisniewski [:twisniewski]]

I'm afraid that I only have an S7 Edge, and no other Samsung devices to test with :(

Comment 10

[Makoto Kato [:m_kato]]

OK, I will get S7 due to no S7 edge.

Comment 11

[Makoto Kato [:m_kato]]

Since I get Galaxy S7, although I test this, it depends on setting of Samsung keyboard.

If turning off [Smart typing] - [Predictive text] on Samsung Keyboard, keypress is fired. But if turning on it, that event isn't fired. Because text is composing string. (So keydown, input and keyup are fired).

Thomas, do you turn on [Predictive text] on Samsung Keyboard?

Also, as long as Chrome 72, keypress isn't fired with this setting. Is keypress fired on Chrome 72 with [Predictive text] ?

Comment 12

[Thomas Wisniewski [:twisniewski]]

Ah, yes, you're right, when I disable predictive text (the default on my phone), then the keypress events are sent. Chrome also isn't showing the events when predictive text is on.

How strange. I will have to check the related webcompat issue again, as Chrome was working with it at the time where Firefox was not (I had not changed the predictive text setting at that time).

Comment 13

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 14

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 15

[Makoto Kato [:m_kato]]

Thomas, do you have any update per comment #12? As long as I test on Chrome, event order is same as Chrome.

Comment 16

[Chris Peterson [:cpeterson]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #12)

Ah, yes, you're right, when I disable predictive text (the default on my phone), then the keypress events are sent. Chrome also isn't showing the events when predictive text is on.

How strange. I will have to check the related webcompat issue again, as Chrome was working with it at the time where Firefox was not (I had not changed the predictive text setting at that time).

Thomas, can you still reproduce this keypress event bug? Is it reproducible in Fennec and Fenix/GeckoView?

Comment 17

[Thomas Wisniewski [:twisniewski]]

Yes, there is still a difference. This is still the current situation on my phone for the testcase:

• with Samsung Keyboard's predictive text ON, none of the browsers (Chrome, Fennec and Fenix) send keypress events.
• with Samsung Keyboard's predictive text OFF, Chrome still sends no keypress events, but both Fennec and Fenix do send them.

Comment 18

[Makoto Kato [:m_kato]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #17)

Yes, there is still a difference. This is still the current situation on my phone for the testcase:

• with Samsung Keyboard's predictive text ON, none of the browsers (Chrome, Fennec and Fenix) send keypress events.
• with Samsung Keyboard's predictive text OFF, Chrome still sends no keypress events, but both Fennec and Fenix do send them.

Original issue is that "Desktop Firefox and Chrome mobile do fire the events." But all situation of Chrome mobile doesn't fire keypress event. So this is different from original issue (https://webcompat.com/issues/17247). If we don't fire keypress, is https://webcompat.com/issues/17247 fixed? I think that we need test/investigate this again what issue occurs.

Comment 19

[Thomas Wisniewski [:twisniewski]]

Indeed, I just tried running a local instance of Jupyter Notebook, and both Fennec and Fenix seem fine with editing text on it now.

Comment 20

[Chris Peterson [:cpeterson]]

(In reply to Thomas Wisniewski [:twisniewski] from comment #19)

Indeed, I just tried running a local instance of Jupyter Notebook, and both Fennec and Fenix seem fine with editing text on it now.

Awesome. In that case, I'll close this bug as fixed. :)