1031561 - [B2G][Keyboard]Caps Lock is not always properly visually represented

Status: VERIFIED FIXED

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

Description

[Ross Kuhlman ([e-mail])]

Attachment: CapsLockComparison.jpg

There are two ways to set the keyboard into Caps Lock mode. If the user taps the shift key twice in a row, caps lock is turned on and visually represented by the shift key being underlined in blue and the shift icon glows blue. If the user taps the shift key once, types a letter, and taps the shift key again, Caps Lock will be engaged, but visually, it looks like the shift key has only  been tapped once. The button is blue and the shift icon is white.

Repro Steps:
1) Update a Flame to BuildID: 20140627040205
2) Launch Messaging app and start a new message.
3) Tap in compose text area. (Shift key should be highlighted by default)
4) Tap a single letter on the keyboard
5) Tap shift key again and observe visual state. (Caps Lock is enabled)
6) Type a few letters and hit spacebar. (Letters should all be capitalized)
7) Double tap shift key and observe visual state.
8) Compare shift key appearance from step 5 to appearance from step 7

Actual:
Caps Lock indicator looks different depending on how caps lock is initiated

Expected:
Caps Lock is always visually represented in the same way

Master M/C Environmental Variables:
Device: Flame Master M/C MOZ
BuildID: 20140627040205
Gaia: b8f36518696f3191a56e4f33447ee9d6ec820da1
Gecko: 9290d7995f98
Version: 33.0a1
Firmware Version: v122

Notes:

Repro frequency: 100%
See attached: logcat, screenshot

Comment 1

[Ross Kuhlman ([e-mail])]

Attachment: CapsLockComparison.jpg

Attaching screenshot of issue

Comment 2

[Ross Kuhlman ([e-mail])]

adding qawanted to determine if issue occurs on v1.4 and v2.0

Comment 3

[Cody Roesch [:croesch]]

This bug repro's on: Flame 2.1 Master, Flame 2.0, Flame 1.4, Buri 2.1

Actual Results: Shift key gets an abnormal highlight.

Environmental Variables:
Device: Flame Master
Build ID: 20140630063630
Gaia: bc3bbf42d2a606f6b7038881cff5ec3795fdf953
Gecko: 3b46de297f3f
Version: 33.0a1 (Master)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Flame 2.0
Build ID: 20140630085228
Gaia: 564ab3935206a6979b317597020f47aebe8c80fe
Gecko: 7974d58adda4
Version: 32.0a2 (2.0)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Flame 1.4
Build ID: 20140629211929
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Version: 30.0 (1.4)
Firmware Version: v122
---------------------------------------------
Environmental Variables:
Device: Buri Master
Build ID: 20140630063630
Gaia: bc3bbf42d2a606f6b7038881cff5ec3795fdf953
Gecko: 3b46de297f3f
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg

Comment 4

[Joshua Mitchell (Inactive)]

not a regression

Comment 5

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

For the case 2, "If the user taps the shift key once, types a letter, and taps the shift key again", this is a feature that you could easily type acronym this way, and in my opinion, this is not in "Capslock" mode, since after your press [space] key, it would change back to lowercase.

When in "Capslock" mode, after you press [space] key, the capslock mode will still be on, so you could continue to type in uppercase.

I don't think there is an issue here, but I'll ask Omega, our keyboard UX, to double confirm we don't need to change the behavior.

Comment 6

[Omega Feng [:Omega] [:馮於懋]]

(In reply to Rudy Lu [:rudyl] from comment #5)
> For the case 2, "If the user taps the shift key once, types a letter, and
> taps the shift key again", this is a feature that you could easily type
> acronym this way, and in my opinion, this is not in "Capslock" mode, since
> after your press [space] key, it would change back to lowercase.

I think this feature confuses users. Let's remove it if there are no any other concerns.

Comment 8

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Patch V1

This is a simple patch to remove a "feature" that sometimes confuses the tester.

David, could you please help review this?
Thank you.

Comment 9

[David Flanagan [:djf]]

Comment on attachment 8463930 [details] [review]
Patch V1

I think it was kind of a cool feature. The main point was that if you move the cursor to edit a word that is in all caps, you'll automatically get all caps, which I thought was kind of nice.

But I agree that removing it is easier than trying to implement a true locked state.

Note that I did not actually run the code to test the patch.

Comment 10

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Landed to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/80a452a2615446839482ee98a0744285d723f531

--
David, thanks, I thought it was cool actually, but sorry to remove this per UX requirement.

Comment 14

[howie [:howie]]

Hi Rudy, can you request uplift this to 2.0? Thanks.

Comment 15

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Comment on attachment 8463930 [details] [review]
Patch V1

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): N/A, this is done by removing a confusing feature. 
[User impact] if declined: The user would not know why the keyboard keeps Capslocked when there are more than 2 uppercase letters in front.
[Testing completed]: yes, unit test + manual test.
[Risk to taking this patch] (and alternatives if risky): low, this stays on master for a while.
[String changes made]: N/A

Comment 16

[bhavana bajaj [:bajaj]]

Comment on attachment 8463930 [details] [review]
Patch V1

Adding verifyme for QA to help verify this once it lands.

Comment 17

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Seems this needs a v2.0-specific patch, so I created a pull request first,
https://github.com/mozilla-b2g/gaia/pull/24469/files

Waiting for CI result.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/d818e99094a119aebf7d0a9fa0db3e99b66f9046

Comment 19

[Kai-Zhen Li [:seinlin][:kli]]

v2.0m: https://github.com/mozilla-b2g/gaia/commit/256fcf95d088a05e66e59e4a1417542ca5ab8140

Comment 20

[William Hsu [:whsu]]

Verified it on latest v2.0 build.
Cannot reproduce this bug.

Attach the screenshot. (2014-10-06-19-04-58.png)

* Build information:
 - Gaia      092d2b7678774c8b0b06dca0e0a8119e9eafdec3
 - Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/69ca61f7edf3
 - BuildID   20141006000202
 - Version   32.0

Comment 21

[William Hsu [:whsu]]

Attachment: 2014-10-06-19-04-58.png

Comment 22

[Coler]

Verify passed, this issue can't be repro on  Woodduck 2.0; Flame2.0&2.1.
Attachment:Verify_Woodduck_Keyoard.MP4
Reproducing rate: 0/5

Woodduck 2.0 build:
Gaia-Rev        60146ec47cd38a8be8ed22e0116902eceb9ac067
Gecko-Rev       cdfbe9866cf0b71b33454926638ce0cd8bb1fb00
Build-ID        20141117050313
Version         32.0
Flame 2.0 build:
Gaia-Rev        086a668942292168f312b3bb53e275fa0886fab1
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a57b299c5cf2
Build-ID        20141116000206
Version         32.0

Flame2.1 build:
Gaia-Rev        81160ad79e5b4c21967418dd63f1a1d08d77924e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/3572aa3e6766
Build-ID        20141116001201
Version         34.0

Comment 23

[Coler]

Attachment: Verify_Woodduck_Keyboard.MP4