669361 - ASUS Transformer and Slider hardware keyboard is always en-US (pre-Jelly Bean)

Status: VERIFIED FIXED

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

Description

[Mike Hommey [:glandium]]

When using the asus transformer hardware keyboard, whichever keyboard layout is configured (using the one corresponding to the system language when the language is not en-us, using a specific selection), the keys that fennec gets are always that of an en-us keyboard.

It however gets proper keys from the soft keyboard.

Comment 1

[Aaron Train [:aaronmt]]

SUMO User Report -> https://support.mozilla.com/en-US/questions/844343

Comment 2

[Aaron Train [:aaronmt]]

Not just the Transformer, report of LG LU2300 -> https://support.mozilla.com/en-US/questions/848586#answers

Comment 3

[Violhaine Grimly]

On the Transformer (french AZERTY dock keyboard, Android 3.2), the delete key eats at least two chars each time under FF Mobile Beta (did not test the stable release).

Comment 4

[Mike Hommey [:glandium]]

(In reply to comment #3)
> On the Transformer (french AZERTY dock keyboard, Android 3.2), the delete
> key eats at least two chars each time under FF Mobile Beta (did not test the
> stable release).

This is bug 662219

Comment 6

[Thomas Arend [:tarend]]

Issues have also been reported with the Bluetooth keyboard and the Galaxy Tab - that keyboard also seems to be stuck in en-US only.

Comment 7

[Alex Pakhotin (:alexp)]

Tried Galaxy Tab 10.1 with a Bluetooth keyboard, and it seems to be working as it should - I could enter Russian text with it. I had to switch the language on the software keyboard ("Samsung keypad") though. Not sure if there are other ways to switch it in such configuration.

Apparently there is something specific to the Transformer.

Comment 8

[Mike Hommey [:glandium]]

You know what ? It actually looks like it's fixed. I hadn't noticed because I haven't been using the hardware keyboard with fennec lately, but it does work now. I double checked that the Firefox 6 install I have does have the problem and it does, which suggests this is not something that was solved by the upgrade to honeycomb 3.2.

Comment 9

[Francesco Lodolo [:flod]]

I was searching bugzilla because I was having the same problem, then I discovered that switching from Asus Keyboard (language) to Android Keybooard and then back to Asus Keyboard solves the problem (at least for me on Asus Transformer).

Comment 10

[Patrick]

I just received an ASUS Transformer, updated it to 3.2 and then installed Firefox 6.0.2.

And this bug is bugging on! Soft Keyboard works. Switching back and forth has no effect on  the bug though.

Problems:

      - backspace key rubs out 2 characters
      - ALL keys are behaving as if the keyboard was in en_US mode (including the famous y and z switched)
      - pg-up / pg-dwn is not working (i have had this issue this with the desktop version of firefox on my pc where it has "magically" disappeared - maybe the same kind of magic hommey described... ?) 

The system default language is en_US and the keyboard has a de_CH layout. All other applications are working correctly but firefox.

Comment 11

[mail]

Works for me in Nightly (nightly.mozilla.org) with Android 3.2. Can those of you who have this problem try nightly?

I also have the dock update that was released a while ago. I don't remember when it was released, and I don't know if the dock update is relevant to this problem.

Comment 12

[Markus Golser]

works for me using the nightly build.

Comment 13

[matejcik]

please reopen, this is still a problem a year later with Firefox stable from Google Play

Comment 14

[matejcik]

my system is Asus Transformer TF101 with ICS 4.0.3
(incidentally, even though it's listed as one of the supported devices, it is apparently disallowed in Google Play, i'll open a new bug about that)

Comment 15

[Aaron Train [:aaronmt]]

Please re-test on Nightly (http://nightly.mozilla.org). Currently our newly released product does not support tablets. Expect an update in the following weeks.

Comment 16

[matejcik]

Yes, Nightly has the same problem.
also it crashed when i tried the workaround from comment 9

Comment 17

[Mauvaisours]

Tested nightly on TF201 with french keyboard. Problem still exists. Note: adress bar works OK, only textboxes exhibit incorrect behaviour.

Comment 18

[Antoine Turmel [:GeekShadow]]

Still have the issue on TF101 with french keyboard too.

Comment 19

[hobbes]

no problem anymore for me with Belgian keyboard on TF101 running CM9 nightly (ICS 4.0.4) and Firefox nighthly. Keyboard is fr_be in address bar and in web pages, and backspace deletes only one char.

Comment 20

[Antoine Turmel [:GeekShadow]]

(In reply to hobbes from comment #19)
> no problem anymore for me with Belgian keyboard on TF101 running CM9 nightly
> (ICS 4.0.4) and Firefox nighthly. Keyboard is fr_be in address bar and in
> web pages, and backspace deletes only one char.

Because I think the issue is on the original Asus rom and keyboard settings

Comment 21

[flyaaway]

same problem with nighthly and toshiba ac100 (have physical keyboard)

Comment 22

[timo]

I have the same issue with Asus TF-300T dock. Keybooard layout is correct in the address bar, but always US in HTML-form. I'm using latest version of Firefox from Google Play (15.0).

Comment 23

[yvesago]

always same issue with firefox beta 16 on assus slider SL101

Comment 24

[Chris Peterson [:cpeterson]]

The problem is that we are dispatching JS key events based on the Android hardware key *codes* (where a QWERTZ keyboard's Z key still returns KEYCODE_Y), instead of honoring the actual changed text.

Comment 25

[timo]

Jelly Bean upgrade on Asus TF-300T seems to fix the problem.

Comment 26

[yldevice]

The same problem with Asus eee Slider. Note: in some versions of FF/FF beta/Aurora ctrl+space did work for changing the language, but mostly in an "unstable" fashion: "now it works, after opening another tab it doesn't" or "previous time I opened FF beta, it worked, now it doesn't" etc. Currently, I'm not able to change the language in each FF 15, FF beta 16 and Aurora 17. This really prevents me from using FF.

Comment 27

[yldevice]

And the thing [e-mail] mentioned for Transformer (in address bar the language changes) is true for Slider, for each FF, FF beta and Aurora.

Comment 28

[Lukas Blakk [:lsblakk] use ?needinfo]

This is not serious enough to chemspill for (again) but let's see if we can get a fix ready to uplift to branches in the next week or so (by Beta 4).

Comment 29

[Chris Peterson [:cpeterson]]

Attachment: asus-transformer-hkb.patch

Ignore non-en_US HKB KeyEvents for Asus Transformer tablets running Honeycomb or ICS.

Asus Transformer tablets generate en-US keycodes for HKB keys, regardless of system locale or keyboard layout. This bug is reportedly fixed in Jelly Bean.

I don't really like the method name `hasBuggyHardwareKeyboardLayout()`. If you have any suggestions, please let me know! :)

Comment 30

[Makoto Kato [:m_kato]]

What IME does Transform use on non-US version?  If Transformer uses special IME (not Android Keyboard), we should use Secure.Settings.DEFAULT_INPUT_METHOD to check keyboard/IME.  Your suggestion code doesn't work other en-US IME using prediction (Actually, it doesn't still work on the latest Fennec, also). 

Also, if onKeyPreIme returns false instead of, I think this can fix this easily.  IME handles key input, so then, it sends correct character via IME method.

Comment 31

[Chris Peterson [:cpeterson]]

(In reply to Makoto Kato from comment #30)
> What IME does Transform use on non-US version?  If Transformer uses special
> IME (not Android Keyboard), we should use
> Secure.Settings.DEFAULT_INPUT_METHOD to check keyboard/IME.

The Transformer's DEFAULT_INPUT_METHOD does not return a different value when a hardware keyboard is connected. The only way we know if a key event is from the hardware keyboard is when onKeyPreIme called.

My patch will return false from onKeyPreIme because onKeyPreIme calls the processKeyDown/processKeyUp methods I changed.

Android calls onTextChanged() with the correct string value. The problem is that onKeyPreIme() is called with an untranslated, en-US keycode. So a QWERTZ keyboard layout will produce a KEYCODE_Y when it should (AFAIK) produce KEYCODE_Z.


> Your suggestion
> code doesn't work other en-US IME using prediction (Actually, it doesn't
> still work on the latest Fennec, also). 

Can you please clarify what you mean by "other en-US IME using prediction"? This bug only affects the Transformer's hardware keyboard.

Comment 32

[Maxim Levitsky]

Still a problem on galaxy tab 10.1 :-(

I use firefox beta.
Note that original firefox didnt have this issue (at least till the latest update which I didnt install on purpose to not have this bug)

Yet I love to switch to latest firefox as it is much better.

Comment 33

[Chris Peterson [:cpeterson]]

hi Maxim, this bug is specifically about the Asus Transformer's hardware keyboard with non-en-US layouts. If you open a new bug report describing the steps to reproduce your Galaxy Tab problem, we can investigate.

Comment 34

[Scoobidiver (away)]

(In reply to Chris Peterson (:cpeterson) from comment #33)
> hi Maxim, this bug is specifically about the Asus Transformer's hardware
> keyboard with non-en-US layouts. 
ASUS Slider is impacted.

Comment 35

[Chris Peterson [:cpeterson]]

Comment on attachment 660217 [details] [diff] [review]
asus-transformer-hkb.patch

Makoto is busy, so I am changing r=? to blassey.

Comment 36

[Brad Lassey [:blassey] (use needinfo?)]

Chris, can you explain what is going on here? Why do these early returns fix the issue and why only when the default locale is en-US?

Comment 37

[Makoto Kato [:m_kato]]

(In reply to Chris Peterson (:cpeterson) from comment #31)
> (In reply to Makoto Kato from comment #30)
> > What IME does Transform use on non-US version?  If Transformer uses special
> > IME (not Android Keyboard), we should use
> > Secure.Settings.DEFAULT_INPUT_METHOD to check keyboard/IME.
> 
> The Transformer's DEFAULT_INPUT_METHOD does not return a different value
> when a hardware keyboard is connected. The only way we know if a key event
> is from the hardware keyboard is when onKeyPreIme called.
> My patch will return false from onKeyPreIme because onKeyPreIme calls the
> processKeyDown/processKeyUp methods I changed.

onKeyPreIme should handle KEYCODE_MENU/KEY_CODE_BACK/KEYCODE_VOLUME_UP/KEYCODE_VOLUME_DOWN.  Current fix eats these keys by IME since all key returns false.

See xul version code of GekcoInputConnection.java.

> Android calls onTextChanged() with the correct string value. The problem is
> that onKeyPreIme() is called with an untranslated, en-US keycode. So a
> QWERTZ keyboard layout will produce a KEYCODE_Y when it should (AFAIK)
> produce KEYCODE_Z.

Yes.  correct.

> > Your suggestion
> > code doesn't work other en-US IME using prediction (Actually, it doesn't
> > still work on the latest Fennec, also). 
> 
> Can you please clarify what you mean by "other en-US IME using prediction"?
> This bug only affects the Transformer's hardware keyboard.

This issue is for all Android hardware keyboard input, not Transformer only.

If there is hardware keyboard w/ IME supports prediction like swiftkey on software keyboard, prediction input by IME doesn't work since onKeyPreIme returns true on NativeFennec.  As long as I know, this is no IME for this now .  So please ignore this.

Comment 38

[Maxim Levitsky]

@Chris Peterson @Makoto Kato

> This issue is for all Android hardware keyboard input, not Transformer only.

This is why I commented on this bugreport and didn't open a new one.

Comment 39

[Chris Peterson [:cpeterson]]

(In reply to Makoto Kato from comment #37)
> onKeyPreIme should handle
> KEYCODE_MENU/KEY_CODE_BACK/KEYCODE_VOLUME_UP/KEYCODE_VOLUME_DOWN.  Current
> fix eats these keys by IME since all key returns false.
> 
> See xul version code of GekcoInputConnection.java.

Thanks. I'll look at the XUL version.


> > Can you please clarify what you mean by "other en-US IME using prediction"?
> > This bug only affects the Transformer's hardware keyboard.
> 
> This issue is for all Android hardware keyboard input, not Transformer only.

Makoto, does this mean my patch should be generic for all hardware keyboard input instead of hardcoding a check for "asus EeePad"? I have not seen any QWERTZ/Y problems with non-Asus devices with slider keyboards. And the Jelly Bean update for the Asus Transformer reportedly fixes this bug (though I can't test this because my Transformer has ICS).

Comment 40

[Chris Peterson [:cpeterson]]

(In reply to Brad Lassey [:blassey] from comment #36)
> Chris, can you explain what is going on here? Why do these early returns fix
> the issue and why only when the default locale is en-US?

Brad, the Asus Transformer tablets generate en-US keycodes for HKB keys, regardless of system locale or keyboard layout. This bug is reportedly fixed in Jelly Bean.

The problem is that Android calls our onKeyPreIme() with an untranslated, en-US keycode. So a QWERTZ keyboard layout will produce a KEYCODE_Y when it should (AFAIK) produce KEYCODE_Z. Returning false from onKeyPreIme() will prevent us from processing the unwanted KEYCODE_Y event, so Android will call our onTextChanged() with the correct string value ('z').

I don't like the method name `hasBuggyHardwareKeyboardLayout()`. If you have any suggestions, please let me know.

Comment 42

[Chris Peterson [:cpeterson]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/90dd2e82f891

Comment 43

[Chris Peterson [:cpeterson]]

If Asus Transformer users are happy with this fix on Nightly 18, I will ask to uplift this fix to Aurora 17.

Comment 44

[Mounir Lamouri (:mounir)]

https://hg.mozilla.org/mozilla-central/rev/90dd2e82f891

Comment 45

[[e-mail]]

Doesn't work for me on ASUS Transformer TF700... Still QWERTY with the deck.

Comment 46

[Scoobidiver (away)]

(In reply to [e-mail] from comment #45)
> Doesn't work for me on ASUS Transformer TF700... Still QWERTY with the deck.
Nightly are built each night, not after each patch land. So wait tomorrow before reporting a failure.

Comment 47

[Aaron Train [:aaronmt]]

(In reply to [e-mail] from comment #45)
> Doesn't work for me on ASUS Transformer TF700... Still QWERTY with the deck.

How about today's Nightly build (09/27) (http://nightly.mozilla.org).

Comment 48

[yvesago]

Nightly is better thanks
but there's no more backspace and arrows :/

Comment 49

[[e-mail]]

(In reply to Aaron Train [:aaronmt] from comment #47)
Keyboard is now correctly recognized, but, same as yvesago, no more backspaces nor arrows.

Comment 50

[Makoto Kato [:m_kato]]

(In reply to [e-mail] from comment #49)
> (In reply to Aaron Train [:aaronmt] from comment #47)
> Keyboard is now correctly recognized, but, same as yvesago, no more
> backspaces nor arrows.

could you file a new bug?   I think that onKeyDown should be ignore hasBuggyHardwareKeyboardLayout().  (although I comment this by commnet #37, chris doesn't care this yet.)

Comment 51

[[e-mail]]

(In reply to Makoto Kato from comment #50)
> (In reply to [e-mail] from comment #49)
> > (In reply to Aaron Train [:aaronmt] from comment #47)
> > Keyboard is now correctly recognized, but, same as yvesago, no more
> > backspaces nor arrows.
> 
> could you file a new bug?   I think that onKeyDown should be ignore
> hasBuggyHardwareKeyboardLayout().  (although I comment this by commnet #37,
> chris doesn't care this yet.)

Done: Bug 795224

Comment 52

[matejcik]

...did you just resolve the dependent bug by reverting the fix to this one?

Comment 53

[Chris Peterson [:cpeterson]]

matejcik, Makoto fixed dependent bug 795224 without reverting this bug's fix. Did you find an Asus keyboard regression?

Comment 54

[matejcik]

no, i got that impression from reading the patches. apparently i misread.
the current Nightly is working perfectly.

Comment 55

[Chris Peterson [:cpeterson]]

We don't need to track this bug for 16 or 17. It would be nice to fix in 17, but it is not a regression (and is fixed in 18).

Comment 56

[Alex Keybl [:akeybl]]

(In reply to Chris Peterson (:cpeterson) from comment #55)
> We don't need to track this bug for 16 or 17. It would be nice to fix in 17,
> but it is not a regression (and is fixed in 18).

Too risky to fix for FF17?

Comment 57

[Chris Peterson [:cpeterson]]

(In reply to Alex Keybl [:akeybl] from comment #56)
> (In reply to Chris Peterson (:cpeterson) from comment #55)
> > We don't need to track this bug for 16 or 17. It would be nice to fix in 17,
> > but it is not a regression (and is fixed in 18).
> 
> Too risky to fix for FF17?

No. The fix should be pretty safe because it changes for device type and OS version so it only affects a subset of Asus devices running Honeycomb or ICS.

If I uplift this fix to FF17, I will need to remember to uplift bug 795224 too (because it fixed a regression in this bug's patch).

Comment 58

[Chris Peterson [:cpeterson]]

^ s/changes the device type/checks the device type/

Comment 59

[Chris Peterson [:cpeterson]]

Comment on attachment 660217 [details] [diff] [review]
asus-transformer-hkb.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Android OS bug
User impact if declined: Asus Transformers' hardware keyboards will always have en-US key layouts, regardless of user locale.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): The fix should be pretty safe because it checks for device type and OS version so it only affects a subset of Asus devices running Honeycomb or ICS. Asus devices running Jelly Bean don't need this workaround.
String or UUID changes made by this patch: N/A

Also, this patch had a regression that was fix by bug 795224, so that bug's patch will also need a+ to be uplifted.

Comment 60

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 660217 [details] [diff] [review]
asus-transformer-hkb.patch

approved the patch in bug 795224 to go along with this, please land before merge day oct 8th.

Comment 61

[Chris Peterson [:cpeterson]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/4411e891e61f