Closed Bug 1157496 Opened 10 years ago Closed 10 years ago

[Keyboard] Double tapping the 'shift' key may not enable 'caps lock'

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 unaffected, b2g-v2.2 affected, b2g-master verified)

RESOLVED FIXED
Tracking Status
b2g-v2.1 --- unaffected
b2g-v2.2 --- affected
b2g-master --- verified

People

(Reporter: onelson, Assigned: rudyl)

References

()

Details

(Keywords: regression, Whiteboard: [3.0-Daily-Testing])

Attachments

(3 files)

Description: When the user attempts to enable 'cap locks' by double tapping the shift key, they may observe that the key will highlight and then darken again, loosening the caps. Expected behavior from double tapping the shift key when present case is lower is to enable 'caps lock'. Have observed this issue in Messages, Search Bar and (most prominently) in FTU connecting to a Wi-Fi network password field. Repro Steps: 1) Update a Flame to 20150422010202 2) Progress through FTU to Wi-Fi Networks 3) Select password-protected network to join 4) When focus is in password field and keyboard is active, double tap shift key ** perform step 4) in Messages Subject/Body field (probably anywhere keyboard is available) Actual: Shift Key does not lock into caps lock after double tap; resets to lower-case Expected: Shift key locks into caps lock, arrow highlights with underline Environmental Variables: -------------------------------------- Device: Flame 3.0 Build ID: 20150422010202 Gaia: 15134b080b5f406e5aa36f5136c17dafb4e31f64 Gecko: 946ac85af8f4 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Environmental Variables: Device: Flame 2.2 (319mb)(Kitkat)(Full Flash) Build ID: 20150421002501 Gaia: 828dd03a0e3b140d74b2e49355197df4d91d9227 Gecko: 36f72a3efb9b Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Device: Flame 2.1 BuildID: 20150416001203 Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c Gecko: c54aa1be51d6 Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 34.0 (2.1) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 -------------------------------------- Repro frequency: * 7/10 in FTU Password field * 1/10 for rapid tapping in Messages See attached: video- https://youtu.be/P8pI48Z7nr4 logcat
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
NI on component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(gchang)
This is more like a polish issue. Add developer to cc.
Flags: needinfo?(gchang)
From the bug description, it seems this is not a regression. And after looking at the video, I would rather think this is a normal behavior for the last tapping (star t from about 00:06 of the video). 1. Keyboard is in CapsLock. 2. You double tap on the shift key, so it is still in CapsLock. 3. You tap [Shift] key again -> so it is in lowercase mode. For the current design, what we can do is modify the behavior at step #2, so that double tapping on [Shift] key in CapsLock won't make it still capslocked. But this might need some UX input. Hi Oliver, Could you please help confirm you could reproduce this from v2.1 to v3.0, right? Do you still think this is an issue we need to address with the above explanation? Thanks.
Flags: needinfo?(onelson)
So on revisting this, it appears to be a regression and as it doesn't seem to repro on 2.1 (at least to the degree I can reproduce on 2.2 and 3.0). I strongly believe there is an issue, although behavior throughout keyboard after the FTU seems more limited, which seemed odd to me. I've created two videos which hopefully demonstrate the issue more transparently. This is encountered daily and voiced by other testers, as this is a simple use case from entering our password in the FTU after a fresh flash/reset performed multiple times daily. Repro Steps: ================ 0) Update phone to 20150427010202 --- FTU [ Repro Rate 7/8 ] --- 1) Navigate to 'Network Connections' in FTU 2) Select a network and navigate to entering password 3) Tap 2 letter keys and then proceed to double-tap shift to attempt enabling caps-lock --- Messages [ Repro Rate 5/10 ] --- 1) Navigate to Messages 2) Open a new Message 3) Reveal the keyboard (tap into text field) 4) Tap 2 letter keys and then proceed to double-tap shift to attempt enabling caps-lock ================ Actual Results: Double tapping shift enables shift and then disables shift. No caps-lock. ** FTU: https://youtu.be/ROUH8VDaQRQ ** Messages: https://youtu.be/vugjObdWTiE Expected Results: Double tapping shift quickly enables caps-lock Environmental Variables: ************************* Device: Flame 3.0 Build ID: 20150427010202 Gaia: b4c949cdc780893897c9b45c1adea46e2eb694ff Gecko: 37d60e3b8be6 Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b Version: 40.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0 Device: Flame 2.2 BuildID: 20150427002504 Gaia: 265ca0bc9408c21fc4b25a259fcee7fb642cd06b Gecko: 1908685d798d Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429 Version: 37.0 (2.2) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 *************************
Flags: needinfo?(onelson) → needinfo?(rlu)
I'll take a look this week.
Assignee: nobody → rlu
Flags: needinfo?(rlu)
Status: NEW → ASSIGNED
Comment on attachment 8608481 [details] [review] [gaia] RudyLu:keyboard/Bug1157496-double_tapping_capslock > mozilla-b2g:master This is a simple patch to clear the doubleTapTimer when we set a new one or otherwise the double tapping would be reset (as a result of the timer). Example sequence for this bug: -> Tap 'A' ((set the first doubleTapTimer) -> Tap 'Shift key' (set the second doubleTapTimer) -> The first doubleTapTimer fires, and reset the timer and thedoubleTapPreviousTarget. -> Tap 'Shift key' again Since the timer has been reset, so does not trigger double tapping behavior. The solution is we should clear the first timer when we set another one. Tim, Could you please help review if this is a proper fix? Thank you.
Attachment #8608481 - Flags: review?(timdream)
Comment on attachment 8608481 [details] [review] [gaia] RudyLu:keyboard/Bug1157496-double_tapping_capslock > mozilla-b2g:master Look like a logic error we both overlooked in bug 963096. Thanks for quick turn over.
Attachment #8608481 - Flags: review?(timdream) → review+
Keywords: checkin-needed
http://docs.taskcluster.net/tools/task-graph-inspector/#5XQcu1vGQai3kNIcs5-z8w The pull request failed to pass integration tests. It could not be landed, please try again.
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attached video Verified Video:1605.mp4
This bug has been verified successfully on latest Flame v3.0 & Nexus5 v3.0 STR: 1) Update a Flame to 20150531160203 2) Progress through FTU to Wi-Fi Networks 3) Select password-protected network to join 4) When focus is in password field and keyboard is active, double tap quickly shift key. (Note: Only when you tap shift key very quickly can the bug be reproduced in the former versions.) Actual results: When focus is in password field and keyboard is active in the progress through FTU to Wi-Fi Networks, shift key locks into caps lock after you double tap shift key, arrow highlights with underline. See attachments:1605.mp4 Occur Recurrence: 0/5 Device information: Nexus5 v3.0 build:(pass) Build ID 20150531160203 Gaia Revision e6dc0f4c583407a4a52a66ce7cb11f058302a762 Gaia Date 2015-05-29 17:20:26 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f8d21278244b Gecko Version 41.0a1 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150531.192050 Firmware Date Sun May 31 19:21:07 EDT 2015 Bootloader HHZ12f Flame v3.0 build:(pass) Build ID 20150531160203 Gaia Revision e6dc0f4c583407a4a52a66ce7cb11f058302a762 Gaia Date 2015-05-29 17:20:26 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f8d21278244b Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150531.192324 Firmware Date Sun May 31 19:23:35 EDT 2015 Bootloader L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+] [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: