Closed Bug 1157496 Opened 9 years ago Closed 9 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)

Attached file logcat_20150422_1545.txt (deleted) —
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]
[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]
[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+
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.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Attached video Verified Video:1605.mp4 (deleted) —
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: