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
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.
Masayuki, is this a known bug? Thanks.
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.
(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
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).
Whiteboard: [webcompat] → [webcompat][geckoview]
Priority: P5 → P2
Whiteboard: [webcompat][geckoview] → [webcompat][geckoview:fenix:p2]
Webcompat Priority: --- → ?
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.