I am splitting this bug off bug 630576 (which only addresses key events when an input form is not focused). STR: 1. Load attached testcase web page 2. Tap input focus to the form 3. Type keys ER: * Test results for desktop browsers: Firefox, Chrome, and Safari on Mac OS X 10.7: keydown keypress input keyup AR: Fennec's actual results depend on the device: * Fennec on the Galaxy Nexus: input * Fennec on the Samsung S2: input input * Fennec on the Droid Pro: input keyup * Fennec on the Kindle Fire: input --- For comparison, here are the test results for other Android browsers: * Stock browser on the Galaxy Nexus, Galaxy S2, and Droid Pro: keydown keypress input keyup * Chrome on the Galaxy Nexus: keydown input keyup

Confirmed on Huawei Honor (ICS 4.0.3) * no keyup event in Fennec 14 * keyup in Opera mini/mobile * keyup in android browser

I just tested this on Firefox for Android with Google Maps (which uses auto-completion). The search starts only when a space is entered, not with the other letters.

This bug is so annoying, is it hard to fix? @jchen I never dev on Firefox for Android, is it something suitable for a newcomer?

nigelb noticed this on SeatGuru; it totally breaks searching for a plane, which is the whole point of the site. That was Bug 1041669.

This also breaks autocomplete on diaspora*. What can I do to see someone working on this?

This appears to happen with the Android built in touch screen keyboard on Firefox 39 / Lollipop 5.1.1 / Android Nexus 9 This appears to be ok (onkeydown() is fired) with the same tablet using a bluetooth keyboard.

This is also happening on Fennec 42. The codepaths are completely different for IME & batchEdit vs. keyPress

Hm, we have seen some breakage here, including Yahoo and Google properties (I *assume* bug 1145662 is another instance of this), so we should probably have a more careful look at this. Usually, I'd suggest sites to listen to `change` instead, as it is a more reliable solution in general, but folks seem to depend on keyboard events, even on mobile. Mike, given the potential impact here (and the fact that this has webcompat+ already), do you know someone working on Fenenc's Input/IME at the moment to needinfo here?

I think Andrew could best redirect the needinfo? (See Comment #13 for more context)

Usually I ask Masayuki about these types of things so let's see if he has an opinion on what could/should be done here.

I'm not so familiar with Android's key event handling (i.e., under widget/android). According to the symptom, I bet that we need to fix bug 354358 and/or you meet these cases: https://searchfox.org/mozilla-central/rev/062e1cf551f5bf3f0af33671b818f75a55ac497b/widget/android/GeckoEditableSupport.cpp#601,615 Anyway, jchen may have some ideas.

If changing "dom.keyboardevent.dispatch_during_composition" to true fixes what you see, only bug 354358 is the cause. I think that making it to true only on Android is fine if it doesn't cause any problem in our UI.

We do send "dummy" key events for sites that only listen to "keyup"/"keydown"/"keypress" for web compat (see bug 1112212). We turn off this web compat behavior for sites that also listen to "input", with the assumption that the site correctly handles "input" events instead. That booking site does listen to "input", but apparently doesn't handle it correctly, making me think it's a bug on their end.