User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Steps to reproduce: Attempted to enter numerals into field using the physical keyboard on both a Sony Ericsson Xperia Pro and Xperia Mini Pro. Actual results: Only the letters on the same button appear (eg, instead of '1' get a 'Q'). Expected results: The relevant number should appear after pressing the "Alt" equivalent button on the phone
Which version of Firefox on Android did you test this with? Is it the same on Nightly (http://nightly.mozilla.org), and Aurora (http://www.mozilla.org/en-US/mobile/aurora/)?
(In reply to Aaron Train [:aaronmt] from comment #1) > Which version of Firefox on Android did you test this with? > > Is it the same on Nightly (http://nightly.mozilla.org), and Aurora > (http://www.mozilla.org/en-US/mobile/aurora/)? Yes - I've just downloaded and checked both with Aurora and the nightly build, and the same problem detailed above still occurs. With a bit more experimentation, I note that all three versions I've tried (14, Aurora, today's nightly build) will allow the keyboard to go into the "function" setting if it's held down for quite some time; the "function" icon shows in the notification bar. When the function key is held down while pressing a number the appropriate number will show up on the screen; however, should I press any more than one button, next time I try any of those buttons again, the whole sequence will be entered! By this I mean: Press function and 2 keys - "2" shows on the screen Press function and 3 keys - "3" shows on the screen (namely, screen reads "23" - as you'd expect) Press function and 2 keys - "23" shows on the screen! I note the "function" symbol in the notification bar also remains visible after accessing it (even though a letter will be displayed when pressing a button - unless the "function" key is held) - it only returns to the default (alphabetical) when leaving that text box and re-entering it (or a new box). Sorry for the confused language - not really reported on these faults before.... Cheers
Thanks, Jonathan. I have ordered a Sony Xperia Mini Pro so I can debug these keyboard problems. I'm just waiting for it to arrive. <:)
QA Mountain View has a Mini pro. If anyone wants to do testing on it, please let us know.
I am using Firefox mobile 14.0.1 in my Xperia mini pro. I also got the problem when using the h/w keyboard. In the "address" field. The keyboard is working fine. I could use the left lower corner button to enter the alt character(blue text). But it doesn't work if the text field generate by the website(i.e any html form field). I found that I need to press & HOLD the alt key and press other keys when I want to input the BLUE character.
Most likely the same issue as bug 766317?
Leo, thanks for your bug notes. I just received my Xperia Mini Pro, so I can begin investigating this bug.
The problem is that Firefox is not recognizing the keyboard's ALT LOCK mode. For the time being, two workarounds: 1. Hold down ALT key then simultaneously press number key 2. or use virtual keyboard <:)
Created attachment 654038 [details] [diff] [review] remove-ALT-special-case.patch Remove special casing of ALT key codes that broke ALT locking. This bug was a regression from Droid Pro bug 699792, which was a regression from XUL Fennec bug 599811. I am paranoid that my patch must have broken *something*, but the test cases for these bugs all work correctly with my patch (for both HKB and VKB). One small bug: the Sony Xperia has an "ALT Lock" icon in its status bar. The ALT key state is supposed to toggle the icon's appearance. With my patch, the icon's appearance does not change, even though the ALT lock behavior works correctly.
Landed on Nightly 17. We should consider uplifting this to 16, but I would like this fix to bake on Nightly for a few days first. https://hg.mozilla.org/integration/mozilla-inbound/rev/3d75661e7e21
Comment on attachment 654038 [details] [diff] [review] remove-ALT-special-case.patch [Approval Request Comment] Bug caused by (feature/regressing bug #): This bug was a regression from Droid Pro bug 699792, which was a regression from XUL Fennec bug 599811. User impact if declined: Users with Sony Ericsson Xperia Pro and Xperia Mini Pro phones will (still) be unable to enter numbers (!!!) or accented characters using the Xperia's HKB. As workaround, users can enter numbers with the VKB. Testing completed (on m-c, etc.): m-c for ~4 days and m-a for 1 day Risk to taking this patch (and alternatives if risky): This is a risky change because it removes a special case for ALT key handling. (The special case was the cause of the original regressions.) I have tested the original bugs' STR with my patch and everything seems to work correctly. String or UUID changes made by this patch: N/A
MV/SF have this device to verify on Beta?
I have an Xperia Mini Pro in SF.
(In reply to Chris Peterson (:cpeterson) from comment #14) > Risk to taking this patch (and alternatives if risky): This is a risky > change because it removes a special case for ALT key handling. (The special > case was the cause of the original regressions.) I have tested the original > bugs' STR with my patch and everything seems to work correctly. If we think this is risky and has been a longstanding bug, let's not break Beta users for a week before finding regressions. Let's do some QA on this while it's still on Aurora.
akeybl, I'd like to renom this bug for uplifting from Aurora 17 to Beta 16. This fix has been baking in Nightly for ~2.5 weeks and Aurora 18 for ~2 weeks without any major fallout reported. This is a longstanding Sony Xperia bug. So we aren't losing any functionality by NOT uplifting, but we would be fixing a frustrating bug that made Firefox pretty much unusable for Sony Xperia users. QA, I have a Sony Xperia in SF if anyone wants to borrow it.
Verified on an Xperia Mini Pro - Today's Firefox nightly.
Comment on attachment 654038 [details] [diff] [review] remove-ALT-special-case.patch appreciate the extra diligence here, let's take it and verify again before we go to release.