987809 - Shift key is still enabled after we tap the first letter in message box

Status: RESOLVED FIXED

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

Description

[Viorela Ioia [:viorela]]

Attachment: VID_0001.3gp

# STR:
1. Go to Messages app and tap New message
2. Type a phone number
3. Type a message in the message box, then delete it
4. Click on the phone number box
5. Type a message in the message box
Repeat steps 4 and 5 until you see the shift button enabled all the time. 

# Expected results:
Tapping key with shift enabled should should cause the keyboard to switch back to lower

# Actual results: 
Shift key still being selected after we tap a letter

Comment 1

[Jason Smith [:jsmith]]

QA Wanted - can we check what happens on 1.4?

Comment 2

[Robert Chira [:RobertC]]

I could reproduce this on v1.4 if I typed the message faster. That way all (or the first few) letters are uppercase.

This seems to be reproduced only when focussing the input field for the first time. After that you need to change focus on something else then back on the input field to be able to reproduce this.

Comment 3

[Josh Schmitt [Joshs]]

I can repro the bug on the latest 1.4. I am also seeing the same results as comment 2.

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140326000201
Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: V1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

What about 1.3?

Comment 5

[Josh Schmitt [Joshs]]

(In reply to Jason Smith [:jsmith] from comment #4)
> What about 1.3?

Issue does not repro on the latest 1.3

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140326004002
Gaia: 812838ad0fabf51fa14435af562ddac6d26fa936
Gecko: ba97efb0da4b
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 6

[Jason Smith [:jsmith]]

The video here is missing half of the phone displayed. We need an updated video here showcasing the bug.

Comment 7

[Josh Schmitt [Joshs]]

Attachment: Shift_Key.mpeg

I have attached a video of the issue seen.

Comment 8

[Jason Smith [:jsmith]]

Okay - that video spells out that we're failing to have the shift key to disable after typing the first letter.

Comment 9

[Peter Bylenga [:PBylenga]]

Comment 0 and Comment 2 seem to reflect two separate issues.

Using STRs in Comment 0, the regression range is between the last v1.3 and the first buri v1.4 Master using only one finger to input text as shown in video.

First broken build Buri v1.4 build without v1.3 Gaia
v1.4 Environmental Variables:
Device: Buri v1.4 MOZ
BuildID: 20131216040201
Gaia: 358cd74fd2b2ef5d541f71a5d53d65d6a7335424
Gecko: f67feb33a974
Version: 29.0a1
Firmware Version: v1.2-device.cfg

Following Comment 2's STRs of tapping quickly with two inputs I can reproduce the issue on today's Buri v1.3 and the latest Buri v1.1.  

Also I can reproduce 100% with the following STRs:

1. Launch Message app
2. Activate Message Input area by tapping
3. Tap two letter keys at the same time

Actual results: Shift key does not disable

Environmental Variables:
Device: Buri 1.1 MOZ
BuildID: 20140318041202
Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61
Gecko: 2c70ef07c5b3
Version: 18.0
Firmware Version: V1.2-device.cfg

Comment 10

[Jason Smith [:jsmith]]

The window above is incorrect. This test just started failing very recently in our automation on 3/25, so the STR to use here should be mapping onto the issue that happened recently. Please check again.

Comment 11

[Natalya Kot [:nkot]]

The regression-window above needs be retested.

Following STR from comment 0 I could reproduce the issue pretty easy on the latest 1.4 build (20140328000202), but I was unable to repro it (out of ~30 tries) on 20131216040201 build which is specified as first broken in given regression-window.

Will continue working on this bug on Monday.

Comment 12

[Preeti Raghunath(:Preeti)]

1.4+ for qablocker

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Rudy, could you investigate after we have a regression range?

Comment 14

[Florin Strugariu [:Bebe]]

has this been fixed?
It started to pass in our automation build

Gaia      6274b3645b3d41df4aa5a55398b5d106edf1c528
Gecko     https://hg.mozilla.org/mozilla-central/rev/4941a2ac0786
BuildID   20140402040201
Version   31.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Comment 15

[Jason Smith [:jsmith]]

Alright - let's put qawanted here to see if we can confirm comment 14's analysis that this no longer reproduces on trunk.

Comment 16

[Natalya Kot [:nkot]]

(In reply to Florin Strugariu [:Bebe] from comment #14)
> has this been fixed?
> It started to pass in our automation build
> 

Still can reproduce manually... following exactly comment 0 STR: 
1) tap phone n field 
2) type in / delete message (regular user speed)
3) repeat 1) 2) steps a few times (4-6) 
--> Keys get stuck in caps, the keyboard doesn't switch back to lower 

Buri master
BuildID: 20140402040201
Gaia: 6274b3645b3d41df4aa5a55398b5d106edf1c528
Gecko: 4941a2ac0786
Version: 31.0a1
v1.2-device.cfg

Comment 17

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

I'll try to reproduce this issue with automated tests.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Rudy Lu [:rudyl] from comment #17)
> I'll try to reproduce this issue with automated tests.

Note - this only reproduces manually now. Automation appears to not be hitting this issue anymore for some reason.

Comment 19

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

After checking, this is caused by a logic as follows:

 1. When in uppercase mode, click a single key twice would output 2 uppercase keys, say "SS".
 2. When the keyboard sees the input field is "SS", it would stick to all caps mode, because this will make inputting acronym much easier.
    This logic is implemented here,
    https://github.com/mozilla-b2g/gaia/blob/906d75ddbfd789e5a6138dd75df59534ad97cd00/apps/keyboard/js/imes/latin/latin.js#L873

I think this behavior is by design, so I'd like to renominate this if this won't block automated tests.

Comment 20

[Zac C (:zac)]

Rudy, if this in indeed by design then do you think that the shift key should also change its appearance into locked mode? If you look at the video in comment #7 it does not do that.

However I could replicate the test case from comment 2, but not replicate your test case from comment #19, point 1. 

For example this use case:
1. type "something"
2. type a space
3. tap shift key (just once)
4. tap 'S' key twice.. 
Actual: 'something Ss' is entered. shift key does not change into locked mode/appearance.

Comment 21

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

(In reply to Zac C (:zac) from comment #20)
> Rudy, if this in indeed by design then do you think that the shift key
> should also change its appearance into locked mode? If you look at the video
> in comment #7 it does not do that.

From my point of view, I think this design is slightly different from caps-lock.
 - In this case (Double uppercase chars), it would switch to lowercase when you press a space key.
 - Caps lock mode, it would stick to uppercase mode even after you press a space key.

> 
> However I could replicate the test case from comment 2, but not replicate
> your test case from comment #19, point 1. 
> 

Maybe I misunderstand something, but I thought my comment 19 is the same as comment 2.
If not, could you help elaborate what comment 2 is about?

Comment 22

[Zac C (:zac)]

(In reply to Rudy Lu [:rudyl] from comment #21)
> 
> Maybe I misunderstand something, but I thought my comment 19 is the same as
> comment 2.
> If not, could you help elaborate what comment 2 is about?

It is the speed of the tap. The use case you are suggesting as valid requires you to tap really really fast, inhumanly fast!
Try my case from step 20 but change step 4 for these two cases:

Tap S twice super fast, it will stick in uppercase mode.
Tap at a normal speed, the second S will be lower case.

(Hamachi, latest master pvt build).

Comment 23

[Zac C (:zac)]

Rudy and I chatted a bit about this on IRC. He could replicate it as per comment #22.

If it's a valid/expected behaviour then it's unreasonably difficult for the user to reach this flow and they're unlikely to ever reach it, or learn that it's there (thus it's unintuitive). 

Only the automation can reach it because it runs much faster than a typical user.

This still seems either like a bug, or unreliable expected behaviour.

Comment 24

[Jason Smith [:jsmith]]

So I'm confused here. Are we in agreement here that this is a bug to be fixed in gaia or a bug that we need to fix in the test?

Comment 25

[Zac C (:zac)]

We're not sure, there's no agreement.

The automated test runs unusually fast and triggers a keyboard behaviour (locking into shift mode) which Rudy is suggesting is expected behaviour.

But I am contesting that if it is expected behaviour then the user will never reach the behaviour because they have to tap the keys ridiculously fast and incoherently.

We need to know whether it is expected behaviour or not - speak to keyboard UX, perhaps? If it is not then it is a bug in Gaia where the shift key gets stuck on.

If it is expected behaviour then perhaps the timing tolerances need to be changed so the user can reach the behaviour and use it. This bug was raised on the principle of having to tap on the keyboard ridiculously fast to trigger it. After that the test framework *may* need to be changed.

Comment 26

[Jason Smith [:jsmith]]

Triage - this isn't realistic for a user to trigger, so this isn't a blocker. We should update the test to be more tolerant of the timing here to represent a more realistic user scenario.

Over to UI Tests to fix this problem in the test itself.

Comment 27

[Dave Hunt [:davehunt] [he/him] ⌚BST]

While it may not be a dupe, this is almost certainly related to bug 963096

Comment 28

[Florin Strugariu [:Bebe]]

test_sms_with_attachments.py started to pass in today’s build:

Gaia      f3abbd2d0a60f1a1618db93f8b1957cae6de379c
Gecko     https://hg.mozilla.org/mozilla-central/rev/215080b813a7
BuildID   20140414040203
Version   31.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Can someone take a look over this as we have issue with this tests and the Ro networks

Comment 29

[Zac C (:zac)]

(In reply to Dave Hunt (:davehunt) from comment #27)
> While it may not be a dupe, this is almost certainly related to bug 963096

See that kind of thing makes me feel like it's a bug again.


Then if we have to work around it I guess we need to put some logic into the Keyboard app object.

Comment 30

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

Unassign myself first. Please let me know if there is anything I can help with.

Comment 32

[Zac C (:zac)]

This has regressed again today.

It's even easier to replicate now and you can see the shift key switch.

Jan Jongboom has confirmed it's a bug so I won't modify the ui tests logic, although it is causing some tests to fail.

Comment 33

[Florin Strugariu [:Bebe]]

this failed in build:

Gaia      f0463704888881b8ed1619e8d4b0d851b0e0311b
Gecko     https://hg.mozilla.org/mozilla-central/rev/1d0496e30feb
BuildID   20140422040203
Version   31.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Comment 34

[Zac C (:zac)]

This is causing around 3-4 tests (different each time as it can be any test that uses the keyboard) to fail in the automation every day so marking this qablocker.

Needs urgency.

Comment 35

[Jason Smith [:jsmith]]

On what branches are we failing tests here? Just trunk?

Comment 36

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #35)
> On what branches are we failing tests here? Just trunk?

Or is 1.4 still a problem here?

Comment 37

[Zac C (:zac)]

(In reply to Jason Smith [:jsmith] from comment #36)
> (In reply to Jason Smith [:jsmith] from comment #35)
> > On what branches are we failing tests here? Just trunk?
> 
> Or is 1.4 still a problem here?

It can be replicated on v1.4 and master, but the automation sees it on master more often. It's easier to replicate on master. The ease of replication seems to be related to performance.

Comment 38

[Jason Smith [:jsmith]]

Rudy - Can you check this again to see if this is a bug in Gaia?

Comment 39

[Zac C (:zac)]

Janjongboom confirmed to me this is a bug they know about which is why I decided it was OK to mark qablocker here (rather than us workaround it).

Comment 40

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

Hi all,

Thanks for the ni.

Jan,

I guess by bug, you're talking about comment 19 but the state inconsistency that caused by async sendKey() , right?
If yes, could you take this one?
Thanks.

Comment 42

[Florin Strugariu [:Bebe]]

we where able to reproduce this in the latest master build:

Gaia      badc73ee7f108fa631150bded0cc57e92aad810e
Gecko     https://hg.mozilla.org/mozilla-central/rev/e19812f56952
BuildID   20140430040206
Version   32.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

Traceback (most recent call last):
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/.env/local/lib/python2.7/site-packages/marionette_client-0.7.6-py2.7.egg/marionette/marionette_test.py", line 163, in run
testMethod()
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/tests/python/gaia-ui-tests/gaiatest/tests/functional/messages/test_sms.py", line 27, in test_sms_send
new_message.type_message(_text_message_content)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/tests/python/gaia-ui-tests/gaiatest/apps/messages/regions/new_message.py", line 42, in type_message
self.keyboard.send(value)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/app.py", line 232, in send
self._tap(val)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/app.py", line 181, in _tap
self.wait_for_condition(lambda m: not self._is_upper_case)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 54, in wait_for_condition
Wait(self.marionette, timeout).until(method, message=message)
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui.smoketest/.env/local/lib/python2.7/site-packages/marionette_client-0.7.6-py2.7.egg/marionette/wait.py", line 143, in until
cause=last_exc)
TimeoutException: TimeoutException: Timed out after 30.0 seconds

Comment 43

[Jan Jongboom [:janjongboom] (inactive)]

Sorry, I don't know if it's due to the state inconsistency. Can we let any of the other gaia devs take a look at that? Won't be able to fix this week.

Comment 44

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

Right now I don't have bandwidth to look at this, might be able to take a look next week.
Keep the ni so this will be in my queue.

Comment 45

[Jason Smith [:jsmith]]

Given that this is a test blocker for 2.0, I'm going to put this in the nom queue 2.0. For 1.4, I don't see us hitting this that often, so the critical fix is needed here on 2.0.

Comment 46

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #45)
> Given that this is a test blocker for 2.0, I'm going to put this in the nom
> queue 2.0. For 1.4, I don't see us hitting this that often, so the critical
> fix is needed here on 2.0.

Can you confirm this Zac that right now, this is more of a problem for 2.0 for automation, not 1.4? Or are we still seeing a bunch of failures on 1.4 as well?

Comment 47

[Zac C (:zac)]

For automation, this is a problem for v2.0 and Hamachi.

On automation we haven't seen it recently on v1.4.

Comment 48

[Jason Smith [:jsmith]]

Ok - I'll call this a regression from 1.4 --> 2.0 then, since the automation impact only hits 2.0 right now.

Comment 49

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

I'll take a look next week, sorry for the delay.

Comment 50

[Jan Jongboom [:janjongboom] (inactive)]

I have seen this on 1.4 as well (manual usage) and it annoys me so bad I went back to the 1.3 keyboard. I'd like to re-nom for 1.4.

Comment 51

[Zac C (:zac)]

I've seen this on Flame too with the automation so I no longer think it's limited to low-power devices :(

Comment 52

[Jan Jongboom [:janjongboom] (inactive)]

Yeah I saw it on Revolution, which is probably the fastest device there is.

Comment 53

[Jason Smith [:jsmith]]

(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #50)
> I have seen this on 1.4 as well (manual usage) and it annoys me so bad I
> went back to the 1.3 keyboard. I'd like to re-nom for 1.4.

The problem is the revolution isn't a shipping configuration, so it's not really valid to analyze the bad behavior. If we see this on devices such as Flame significantly in an annoying manner, then we can re-evaluate.

Comment 54

[Jan Jongboom [:janjongboom] (inactive)]

There is no way that this is a gecko or hardware problem. I've also seen it on Peak today.

I don't have a @&* Flame because apparently noone in Moz cares about module peers having one so I can't test it.

Plus:

(In reply to Zac C (:zac) from comment #51)
> I've seen this on Flame too with the automation so I no longer think it's
> limited to low-power devices :(

Comment 55

[Jason Smith [:jsmith]]

I need a better analysis of what makes this annoying to know to block this or not.

Comment 56

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

(In reply to Jan Jongboom [:janjongboom] (Telenor) from comment #54)
> There is no way that this is a gecko or hardware problem. I've also seen it
> on Peak today.
> 
> I don't have a @&* Flame because apparently noone in Moz cares about module
> peers having one so I can't test it.
> 

Not sure if this could make you feel better, but I don't have a flame either.
So, please help to wait a little bit longer to see when we're going to have it.

Thanks. :)

> Plus:
> 
> (In reply to Zac C (:zac) from comment #51)
> > I've seen this on Flame too with the automation so I no longer think it's
> > limited to low-power devices :(

Comment 57

[Zac C (:zac)]

(In reply to Jason Smith [:jsmith] from comment #55)
> I need a better analysis of what makes this annoying to know to block this
> or not.

It's primarily a UX issue. The user has an expectation of the shift key turning off after typing the first letter but if it doesn't then the keyboard is stuck in capital/shift mode. Then they have to backspace and re-enter their word in the correct case. Keyboard is an important UX point because it's common to so many apps.

Anyway in comment #39 it was confirmed as a bug too.

and also it is causing intermittent failures on the test automation.

Comment 58

[Jason Smith [:jsmith]]

I know about the intermitents - that's why I argued to block on this for 2.0.

For 1.4 - I think we need to do some exploratory testing to see how likely a user is going to hit this. When Stephen & I looked at this last time, it required a lot of special timing to hit the bug, so it didn't seem likely for a user to hit it. We can take another look though to confirm, so I'm adding qawanted here to do some testing around this bug to see how likely this will happen during typical user scenarios.

Comment 59

[Soledad Penades [:sole] [:spenades]]

Hey there

I just flashed a Flame to the nightly version and I can still reproduce this. Open messages, start drafting one by typing quickly and voilà, ALL CAPS WHICH DON'T GET RESET TO LOWERCASE ONCE YOU START TYPING SLOWER. SORRY ABOUT THE CAPS CANNOT GO BACK UNLESS I DELETE EVERYTHING AND TYPE IT AGAIN BUT YOU KNOW YOU DON'T WANT TO DO THAT ON A TINY PHONE SCREEN.

joking but that's the effect this bug creates ;-)

Comment 60

[Joshua Mitchell (Inactive)]

Was able to reproduce this on the latest 1.4 from our Tinderbox builds.

Exploratory testing results:

I would say that it is unlikely that most users will encounter this based on the following:
To reproduce this bug the user must begin the message by tapping two letters at the same time at which point the shift key will become locked on and every letter will be capitalized. Hitting letters in quick succession does not seem to repro; it needs to be simultaneous button presses; which is difficult to do. There seems to be some function that prevents fat fingers (like mine) from triggering 2 adjacent letters at the same time; it seems to always choose between the two. I can repro it with adjacent letters if I use 2 different fingers but this seems an unlikely behaviour for a user. Hitting the same letter twice rapidly will not repro the issue

Furthermore, once the capital letters trigger on I am able to tap the shift key and all subsequent letters will be in lower-case; reducing the impact of this bug.

Environmental Variables:
Device: Flame 1.4
Build ID: 20140604100718
Gaia: 1f238df7ac68a73a4ceb27391a204c800f38ab1c
Gecko: a7b7f1b579cc
Version: 30.0 (1.4) COM
Firmware Version: v10G-2

Comment 63

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

This should have been addressed with the following commit, 
https://github.com/mozilla-b2g/gaia/commit/f0a8ab7d0b6000cc2c2cd2a201964bafa959858b
with bug 1013570.

Comment 65

[Julien Wajsberg [:julienw]]

(In reply to Joshua Mitchell from comment #60)
> Was able to reproduce this on the latest 1.4 from our Tinderbox builds.
> 
> Exploratory testing results:
> 
> I would say that it is unlikely that most users will encounter this based on
> the following:
> To reproduce this bug the user must begin the message by tapping two letters
> at the same time at which point the shift key will become locked on and
> every letter will be capitalized. Hitting letters in quick succession does
> not seem to repro; it needs to be simultaneous button presses; which is
> difficult to do. There seems to be some function that prevents fat fingers
> (like mine) from triggering 2 adjacent letters at the same time; it seems to
> always choose between the two. I can repro it with adjacent letters if I use
> 2 different fingers but this seems an unlikely behaviour for a user. Hitting
> the same letter twice rapidly will not repro the issue

FTR I get this a lot on my Peak v1.4 (albeit a 1-month-old build) without trying.

Comment 66

[Jan Jongboom [:janjongboom] (inactive)]

Same here, just start typing fast with two thumbs right when the keyboard pops up. Easy peasy to repro. 

Which makes sense, because the related code is also in 1.4.

Comment 67

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

This should have been fixed with bug 1013570 on v1.4, 
see bug1013570 comment16 for details.

Comment 68

[Viorela Ioia [:viorela]]

I was not able to reproduce this issue in the latest v1.4 build.

Env: 
Device: Flame
Gaia      0539be80035bbf318962b2b2f69d45d9d8da5f7e
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/db7d75d0c77a
BuildID   20140612160202
Version   30.0
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

Comment 69

[Sue]

Attachment: video of issue verify

This issue has been verified successfully on Flame v2.0 & v2.1
STR:
1. Launch Messages app -> new a message.
2. Input a phone number.
3. Input some words in the message box, then delete it.
4. Tap on the phone number box.
5. Input some words in the message box, then delete it.
6. Repeat step 4 and step 5 several times.
**The shift key is disable after you input a letter.
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        99e4594c66aa3738d58b0cb44bd885a87a063b6e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f91abc6127d9
Build-ID        20141125000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141125.035023
FW-Date         Tue Nov 25 03:50:34 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141125.040617
FW-Date         Tue Nov 25 04:06:28 EST 2014
Bootloader      L1TC00011880