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

VERIFIED FIXED in Firefox 17

Status

()

Firefox for Android
Keyboards and IME
P2
normal
VERIFIED FIXED
6 years ago
a year ago

People

(Reporter: glandium, Assigned: cpeterson)

Tracking

({mobile, relnote})

Trunk
Firefox 18
ARM
Android
mobile, relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox15-, firefox16- wontfix, firefox17+ verified, firefox18+ verified)

Details

(Whiteboard: HKB)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
SUMO User Report -> https://support.mozilla.com/en-US/questions/844343
Not just the Transformer, report of LG LU2300 -> https://support.mozilla.com/en-US/questions/848586#answers

Comment 3

6 years ago
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).
(Reporter)

Comment 4

6 years ago
(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
Duplicate of this bug: 676773
Keywords: mobile, relnote
Issues have also been reported with the Bluetooth keyboard and the Galaxy Tab - that keyboard also seems to be stuck in en-US only.

Updated

6 years ago
tracking-fennec: --- → ?
Priority: -- → P2
Assignee: nobody → alexp
tracking-fennec: ? → +
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.
(Reporter)

Comment 8

6 years ago
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.
Status: NEW → RESOLVED
tracking-fennec: + → ---
Last Resolved: 6 years ago
Priority: P2 → --
Resolution: --- → WORKSFORME
Target Milestone: --- → Firefox 7
Version: Trunk → Firefox 9
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

6 years ago
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

6 years ago
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

6 years ago
works for me using the nightly build.

Comment 13

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

Comment 14

5 years ago
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)
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

5 years ago
Yes, Nightly has the same problem.
also it crashed when i tried the workaround from comment 9
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 17

5 years ago
Tested nightly on TF201 with french keyboard. Problem still exists. Note: adress bar works OK, only textboxes exhibit incorrect behaviour.
Still have the issue on TF101 with french keyboard too.

Comment 19

5 years ago
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.
(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

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

Updated

5 years ago
Assignee: alex.mozilla → nobody
Component: General → Keyboards and IME
Product: Fennec → Firefox for Android
Target Milestone: Firefox 7 → ---
Version: Firefox 9 → Trunk
(Assignee)

Updated

5 years ago
Priority: -- → P2

Comment 22

5 years ago
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).

Updated

5 years ago
Summary: ASUS Transformer hardware keyboard is always en-us → ASUS hardware keyboard is always en-us

Comment 23

5 years ago
always same issue with firefox beta 16 on assus slider SL101
(Assignee)

Comment 24

5 years ago
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.
Assignee: nobody → cpeterson
Status: REOPENED → ASSIGNED

Comment 25

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

Comment 26

5 years ago
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

5 years ago
And the thing timo@tolleri.net mentioned for Transformer (in address bar the language changes) is true for Slider, for each FF, FF beta and Aurora.
(Assignee)

Updated

5 years ago
Blocks: 712018
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
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).
tracking-firefox15: ? → -
tracking-firefox16: ? → +
tracking-firefox17: --- → +
tracking-firefox18: --- → +
(Assignee)

Comment 29

5 years ago
Created attachment 660217 [details] [diff] [review]
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! :)
Attachment #660217 - Flags: review?(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.
(Assignee)

Comment 31

5 years ago
(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

5 years ago
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.
(Assignee)

Comment 33

5 years ago
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.
Summary: ASUS hardware keyboard is always en-us → ASUS Transformer's hardware keyboard is always en-us
Whiteboard: HKB

Comment 34

5 years ago
(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.
(Assignee)

Updated

5 years ago
Summary: ASUS Transformer's hardware keyboard is always en-us → ASUS Transformer and Slider hardware keyboard is always en-US (pre-Jelly Bean)
(Assignee)

Comment 35

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

Makoto is busy, so I am changing r=? to blassey.
Attachment #660217 - Flags: review?(m_kato) → review?(blassey.bugs)
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?
(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

5 years ago
@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.
(Assignee)

Comment 39

5 years ago
(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).
(Assignee)

Comment 40

5 years ago
(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.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 792736
Attachment #660217 - Flags: review?(blassey.bugs) → review+
(Assignee)

Comment 42

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/90dd2e82f891
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → affected
status-firefox18: --- → fixed
Target Milestone: --- → Firefox 18
(Assignee)

Comment 43

5 years ago
If Asus Transformer users are happy with this fix on Nightly 18, I will ask to uplift this fix to Aurora 17.
https://hg.mozilla.org/mozilla-central/rev/90dd2e82f891
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago5 years ago
Resolution: --- → FIXED
Doesn't work for me on ASUS Transformer TF700... Still QWERTY with the deck.

Comment 46

5 years ago
(In reply to roumensois@gmail.com 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.
(In reply to roumensois@gmail.com 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

5 years ago
Nightly is better thanks
but there's no more backspace and arrows :/
(In reply to Aaron Train [:aaronmt] from comment #47)
Keyboard is now correctly recognized, but, same as yvesago, no more backspaces nor arrows.
(In reply to roumensois@gmail.com 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.)
(In reply to Makoto Kato from comment #50)
> (In reply to roumensois@gmail.com 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

Updated

5 years ago
Depends on: 795224

Updated

5 years ago
status-firefox15: affected → wontfix
status-firefox16: affected → wontfix
(Assignee)

Updated

5 years ago
Blocks: 795431

Comment 52

5 years ago
...did you just resolve the dependent bug by reverting the fix to this one?
(Assignee)

Comment 53

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

Comment 54

5 years ago
no, i got that impression from reading the patches. apparently i misread.
the current Nightly is working perfectly.
(Assignee)

Comment 55

5 years ago
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).
status-firefox15: wontfix → ---
tracking-firefox16: + → ?
tracking-firefox17: + → ?
(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?
tracking-firefox16: ? → -
(Assignee)

Comment 57

5 years ago
(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).
(Assignee)

Comment 58

5 years ago
^ s/changes the device type/checks the device type/
(Assignee)

Comment 59

5 years ago
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.
Attachment #660217 - Flags: approval-mozilla-aurora?
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.
Attachment #660217 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
tracking-firefox17: ? → +
(Assignee)

Comment 61

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/4411e891e61f
status-firefox17: affected → fixed

Updated

5 years ago
Status: RESOLVED → VERIFIED
status-firefox17: fixed → verified
status-firefox18: fixed → verified
You need to log in before you can comment on or make changes to this bug.