737658 - Fennec should raise the same key down/press/up event sequence for input forms, regardless of device type or OS version

Status: RESOLVED FIXED

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

Description

[Chris Peterson [:cpeterson]]

Attachment: testcase

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

Comment 1

[Heiko Klein]

Confirmed on Huawei Honor (ICS 4.0.3)

* no keyup event in Fennec 14
* keyup in Opera mini/mobile
* keyup in android browser

Comment 5

[Flaburgan]

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.

Comment 6

[Flaburgan]

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?

Comment 8

[Richard Newman [:rnewman]]

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

Comment 9

[Flaburgan]

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

Comment 10

[Berend De Schouwer]

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.

Comment 11

[Berend De Schouwer]

This is also happening on Fennec 42.

The codepaths are completely different for IME & batchEdit vs. keyPress

Comment 13

[Dennis Schubert [:denschub]]

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?

Comment 14

[Mike Taylor [:miketaylr]]

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

Comment 15

[Andrew Overholt [:overholt]]

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.

Comment 16

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

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.

Comment 17

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

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.

Comment 18

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

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.

Comment 19

[Makoto Kato [:m_kato]]

Now we are dom.keyboardevent.dispatch_during_composition=true via bug 1137567 etc, do you still have any issue?

As long as I test using Gboard, event type and order are same as Chrome.

Comment 20

[Mike Taylor [:miketaylr]]

Testing on the following:

https://webcompat.com/issues/4852
https://webcompat.com/issues/2022 (same site)
I get expected results (bug if fixed) in Nightly 67, and actual results (bug is visible) in Release 65.

https://webcompat.com/issues/6400 - working now in Nightly 67.

Comment 21

[Makoto Kato [:m_kato]]

Firefox 66 beta also works well

Comment 22

[Chris Peterson [:cpeterson]]

I get expected results (bug if fixed) in Nightly 67, and actual results (bug is visible) in Release 65.

Firefox 66 beta also works well

In that case, I'll resolve this bug (seven years after I filed it!) as fixed in 66.