Closed Bug 1013570 Opened 6 years ago Closed 6 years ago

[B2G][Keyboard]Double or triple tapping on the spacebar can result in 2-3 periods, as well as deleted characters


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.4+, b2g-v1.3 unaffected, b2g-v1.4 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

2.0 S4 (20june)
blocking-b2g 1.4+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified


(Reporter: dharris, Assigned: rudyl)




(Keywords: regression, Whiteboard: [openc-1.4-exploratory])


(4 files)

Attached file Logact Open C 1.4
Double or triple tapping on the spacebar can result in 2-3 periods, as well as deleting characters

Repro Steps:
1) Update a Open_C to BuildID: 20140513000208
2) Open the Calendar app> Tap on '+'
3) Tap inside one of the information fields such as the 'Notes' field
4) Type any number, or letter
5) Quickly tap the spacebar 3 times

Sometimes 2-3 periods will be typed. Sometimes the number is sometimes deleted and replaced with periods. Sometimes there will be a space between the number or letter and the period

The user sees 1 period directly after a number or letter that is typed.

Open C 1.4
1.4 Environmental Variables:
Device: Open_C 1.4
BuildID: 20140516000201
Gaia: 32fca83da31b9a0f9a5a88f96c913a25accdc14b
Gecko: a1e455367fa6
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL

Keywords:Double, Triple, Quickly, Fast, Rapidly, Multiple, Deleted, Removed

Notes: This issue occurs more frequently when using a number. Also the issue can repro after words. This issue occurs on all apps with a Keyboard

Repro frequency: 80% (this includes seeing any of the 3 'Actual' results)
See attached: Logcat, Video -
This Issue DOES occur on the Buri 1.4 and is easier to reproduce

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140519000201
Gaia: defd0650fb9d30c6515d50a89e72d8fb74ce7e62
Gecko: d95594048b36
Version: 30.0
Firmware Version: v1.2-device.cfg
This issue does NOT occur on Buri 1.3

Buri 1.3: 

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140514024003
Gaia: 96e3fa769a436a2182e6d54088fb41386eb2b5b5
Gecko: 685cf1d0dedb
Version: 28.0
Firmware Version: v1.2-device.cfg
This issue DOES occur on Flame 1.4

1.4 Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140520000201
Gaia: 17b102ee8d9a724b62285547cc5f1c5d30bfb01c
Gecko: 95be84248033
Version: 30.0
Firmware Version: v10f-3
blocking-b2g: --- → 1.4?
blocking-b2g: 1.4? → 1.4+
Assignee: nobody → pcheng
Assignee: pcheng → nobody
QA Contact: pcheng
Central Nightly/RIL Regression Window:

Last Working Environmental Variables:
Device: Buri MOZ
BuildID: 20140102040201
Gaia: 67a82f88da231969efa4d22df9fb946abf2cf4df
Gecko: 540d85f60c57
Version: 29.0a1
Firmware Version: v1.2-device.cfg

First Broken Environmental Variables:
Device: Buri MOZ
BuildID: 20140103040201
Gaia: 83cc63f728489a24256731adf558354bb2012a59
Gecko: 49d2fce9a86c
Version: 29.0a1
Firmware Version: v1.2-device.cfg

Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce
Gaia: 67a82f88da231969efa4d22df9fb946abf2cf4df
Gecko: 49d2fce9a86c

Last Working Gecko / First Broken Gaia: Issue DOES reproduce
Gaia: 83cc63f728489a24256731adf558354bb2012a59
Gecko: 540d85f60c57

Gaia Pushlog:

A narrower window is not possible for this date.
Hi Tim, may you or Rudy take this? Thanks.
Flags: needinfo?(timdream)
(In reply to Pi Wei Cheng from comment #4)
> Gaia Pushlog:
> 67a82f88da231969efa4d22df9fb946abf2cf4df...
> 83cc63f728489a24256731adf558354bb2012a59
> Note:
> A narrower window is not possible for this date.

Look like bug 952078. Jan, do you have cycles to address this?
Depends on: 952078
Flags: needinfo?(timdream) → needinfo?(janjongboom)
I'll take a look this week.
Assignee: nobody → rlu
Blocks: 952078
No longer depends on: 952078
Whiteboard: [openc-1.4-exploratory] → [openc-1.4-exploratory][ETA: 6/4]
 1. Send the next key after the promise returned by the previous sendKey() invocation is resolved.
 2. In order to also solve bug 987809, we should send the correct keyCode based on the right capitalization state (also after the previous promise is resolved).
    For this change, I think keyboard.js should pass to the input method with a keyObject which contains both the lowercase and uppercase keycodes.

This should be easier to give feedback based on,

Tim, could you please help feedback on the above approach?
Thank you.
Attachment #8432204 - Flags: feedback?(timdream)
Comment on attachment 8432204 [details] [review]
WIP - pull request 19856

With a offline discussion, I am convinced this is a valid 1.4/2.0 solution to the problem. I would like to see proper fix (a queue) implemented in keyboard app itself and not the IME.

I have made some comments on Github to see if we could get a better clarity of this addition.
Attachment #8432204 - Flags: feedback?(timdream) → feedback+
Whiteboard: [openc-1.4-exploratory][ETA: 6/4] → [openc-1.4-exploratory][ETA: 6/6]
Comment on attachment 8432204 [details] [review]
WIP - pull request 19856

Patch updated to address the review comments.

Tim, could you please help review this again?
Thank you.
Attachment #8432204 - Flags: review?(timdream)
Flags: needinfo?(janjongboom)
Comment on attachment 8432204 [details] [review]
WIP - pull request 19856

Discussed offline.
Attachment #8432204 - Flags: review?(timdream)
Comment on attachment 8432204 [details] [review]
WIP - pull request 19856

Hi Tim,

Patch updated for:
 1. Separate the 2 then() functions to make the code easier to read, and add some comments for the handling sequence.

 2. I found we still need to return the promise in click(), or in the tests, we could not know when the clicks have been processed.

 3. It seems that in handleKey() function, we already handle the case when inputContext.sendKey() is rejected, however, for safety, I also add a empty function as the onRejected paremeter to the 2nd then().

Please help review it again and thanks for your patience.
Attachment #8432204 - Flags: review?(timdream)
Attachment #8432204 - Flags: review?(timdream) → review+
Landed to Gaia master,

Tim, thanks for the review.
Closed: 6 years ago
Resolution: --- → FIXED
Needs a branch-specific patch for v1.4 uplift.
Flags: needinfo?(rlu)
Whiteboard: [openc-1.4-exploratory][ETA: 6/6] → [openc-1.4-exploratory]
Target Milestone: --- → 2.0 S4 (20june)
Attached file Patch for v1.4
I have a patch for v1.4 branch, however the Travis CI always failed recently.
Working on bug 1023741 and bug1023694 to get it green again.

Keep the ni so that this will be in my queue.
Depends on: 1034210
Attached video video of issue verify
This issue has been verified successfully on Flame 2.1
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        99e4594c66aa3738d58b0cb44bd885a87a063b6e
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
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
You need to log in before you can comment on or make changes to this bug.