Closed Bug 1475738 Opened 4 years ago Closed 3 years ago

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

Categories

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

defect

Tracking

(Webcompat Priority:?, firefox68 ?)

RESOLVED FIXED
Webcompat Priority ?
Tracking Status
firefox68 --- ?

People

(Reporter: twisniewski, Assigned: m_kato)

References

Details

(Whiteboard: [webcompat][geckoview:fenix:p2])

Attachments

(1 file)

Attached file 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.
Flags: webcompat?
Masayuki, is this a known bug? Thanks.
Flags: needinfo?(masayuki)
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?
Flags: needinfo?(masayuki) → needinfo?(nchen)
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.
Flags: needinfo?(nchen)
(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.
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.
Priority: -- → P5
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
Flags: needinfo?(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).
Flags: needinfo?(twisniewski)
Whiteboard: [webcompat] → [webcompat][geckoview]
Priority: P5 → P2
Whiteboard: [webcompat][geckoview] → [webcompat][geckoview:fenix:p2]
Assignee: nobody → 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)?

Flags: needinfo?(twisniewski)

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

Flags: needinfo?(twisniewski)

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

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] ?

Flags: needinfo?(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).

Flags: needinfo?(twisniewski)

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

Webcompat Priority: --- → ?

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

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

Flags: needinfo?(twisniewski)

(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?

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.
Flags: needinfo?(twisniewski)

(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.

Flags: needinfo?(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.

Flags: needinfo?(twisniewski)

(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. :)

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.