1128566 - [System][input] Tap events register twice (double) in various areas of the OS

Status: RESOLVED WORKSFORME

(Core Graveyard :: Widget: Gonk, defect)

Description

[Martin Shuman [:Marty]]

Description:
In specific areas of the device, tap events are registering two inputs for one tap.

At this point, this behavior is seen occurring in these areas:
-Inputting a passcode at the lock screen, making it impossible to input most passcodes.
-Accepting a call.  Call is answered, and then immediately ended.
-Creating a Smart Collection. Selecting collections from the list will usually select and immediately de-select.
-Toggling settings in the Developer Menu, when tapping specifically on the check boxes.


Repro Steps:
1) Update a Flame to 20150202010229
2) Open the settings app and configure a Passcode
3) Press the power button to lock the device
4) Press the power button again to bring up the lock screen
5) Prompt for a passcode and tap the keypad once.


Actual:
Two events are input for one keypress

Expected:
Single taps only result in one input.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150202010229
Gaia: 740c7c2330d08eb9298597e0455f53d4619bbc1a
Gecko: 940118b1adcd
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Repro frequency: 7/7
See attached: video clip, logcat

-----------------------------------------

This issue does NOT occur on Flame 2.2
Single tap events only result in one input.

Environmental Variables:
Device: Flame 2.2
Build ID: 20150202002507k
Gaia: d6141fa3208f224393269e17c39d1fe53b7e6a05
Gecko: be206fa2fb60
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 1

[Martin Shuman [:Marty]]

Attachment: logcat-double-tap.txt

Comment 2

[Peter Bylenga [:PBylenga]]

[Blocking Requested - why for this release]:
Severe Functional regression that affects multiple apps.

Requesting a window.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hey Kats?  Could you take a look please?
We're checking to see if the regression window has something to do with bug 950934.

Comment 4

[Brogan Zumwalt [Inactive]]

Gecko Regression Window:

Device: Flame 3.0 Master
BuildID: 20150131191033
Gaia: ab69ae06a7f2b54e60ab63b1b44c8d19d5d20d94
Gecko: 4b3d6f5a3f1b
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Device: Flame 3.0 Master
Build ID: 20150131202535
Gaia: ab69ae06a7f2b54e60ab63b1b44c8d19d5d20d94
Gecko: 0038cfaf847a
Version: 38.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Working Gaia with Broken Gecko issue DOES occur:
Gaia: ab69ae06a7f2b54e60ab63b1b44c8d19d5d20d94
Gecko: 0038cfaf847a

Working Gecko with Broken Gaia issue does NOT occur:
Gaia: ab69ae06a7f2b54e60ab63b1b44c8d19d5d20d94
Gecko: 4b3d6f5a3f1b


Mozilla-Inbound Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4b3d6f5a3f1b&tochange=0038cfaf847a


Issue appears to be due to bug 1005815

Comment 5

[Martijn Wargers (dead)]

An automated test like this one, I would have expected to catch this:
http://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/tests/functional/lockscreen/test_lockscreen_unlock_to_homescreen_with_passcode.py
But it's passing with this bug in it.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Yes, this was regressed bug 1005815 but it looks like it was fixed by bug 950534 (which is not in a nightly build yet, as it only merged to m-c this morning). So I don't think backing anything out would help much here. The build at https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame-kk-eng/20150202042034/ for example should not have this problem, at least on the lockscreen. I'm looking into the other STRs provided in comment 0 as well.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Err that should be bug 950934, not 950534.

Comment 8

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #6)
> Yes, this was regressed bug 1005815 but it looks like it was fixed by bug
> 950534

Hmm, you're right. I didn't realize this until now, but the creation of an APZC for the PP-RD-RSF in bug 1124452 wasn't conditional on any of the switches flipped in bug 950934 - so we've actually had APZ in the parent process (for the root frame only, not subframes), ever since bug 1124452 landed.

Then bug 1005815 introduced APZ handling of single-taps - immediately in effect for the root frame thanks to bug 1124452 - and finally bug 950934 simultaneously disabled enabled APZ for subframes too, and disabled the non-APZ codepath for handling single-taps. This means single-taps are being handled twice in revisions between bug 1005815 landing and bug 950934 landing.

Apologies for this confusion.

Comment 9

[Peter Bylenga [:PBylenga]]

I can confirm I cannot reproduce the issue locally on 
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame-kk-eng/20150202042034/

Comment 10

[Martijn Wargers (dead)]

Botond, perhaps you happen to know why an automated test like in comment 5 doesn't catch this issue?
http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js#964
http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js#856
Marionette is creating the touchstart, touchend and click events fine. Why are these not handled twice with this bug around?

Comment 11

[Kartikaya Gupta (email:[e-mail])]

(In reply to Martin Shuman [:Marty] from comment #0)
> -Creating a Smart Collection. Selecting collections from the list will
> usually select and immediately de-select.

This is also fixed with bug 950934.

> -Toggling settings in the Developer Menu, when tapping specifically on the
> check boxes.

This one is a bit odd - if you tap the checkboxes on the rightmost edge then they don't work (or rather, they get tapped twice) but if you tap on the left edge or on the label they work fine. It looks like this is partly because of the touch listeners for the edge swipe. I can look into this but it probably doesn't qualify as a smoketest regression by itself.

I wasn't able to test the incoming call scenario as I don't have a SIM in my Flame, but I'm doing a nexus 4 build which I can do that test on. If anybody else can test that quicker on a build with bug 950934 it would be appreciated.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)
> > -Toggling settings in the Developer Menu, when tapping specifically on the
> > check boxes.
> 
> This one is a bit odd - if you tap the checkboxes on the rightmost edge then
> they don't work (or rather, they get tapped twice) but if you tap on the
> left edge or on the label they work fine. It looks like this is partly
> because of the touch listeners for the edge swipe. I can look into this but
> it probably doesn't qualify as a smoketest regression by itself.

I think this is a result of the injectTouchEvent voodoo that the edge swipe detector does. It's eating the touch mouse events and then generating its own touch events which don't have don't go through the gesture detector and so don't generate the appropriate mouse events. I filed bug 1128672 to deal with this, and leave the current bug to track the "tap events register twice" problem.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

(In reply to Martijn Wargers [:mwargers] (QA) from comment #10)
> Botond, perhaps you happen to know why an automated test like in comment 5
> doesn't catch this issue?
> http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-
> listener.js#964
> http://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-
> listener.js#856
> Marionette is creating the touchstart, touchend and click events fine. Why
> are these not handled twice with this bug around?

Marionette doesn't accurately simulate real user input at the widget level, so it goes through a different code path. Specifically I don't believe it exercised the code that generates mouse events from touch events in the gonk widget code that was the cause of this bug.

Comment 14

[Martijn Wargers (dead)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #13)
> Marionette doesn't accurately simulate real user input at the widget level,
> so it goes through a different code path. Specifically I don't believe it
> exercised the code that generates mouse events from touch events in the gonk
> widget code that was the cause of this bug.

Ok thanks, I filed bug 1128696 for this, to get Marionette to simulate real user input at the widget level.

Comment 15

[Martin Shuman [:Marty]]

This issue is no longer occurring on the latest Flame Nightly. Resolving as WorksForMe.

Environmental Variables:
Device: Flame 3.0
Build ID: 20150202154235
Gaia: 4171327fce4803c52b2fae8071b114a70a3a68a7
Gecko: 3bf7ed413e87
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Comment 16

[Peter Bylenga [:PBylenga]]

Thank you :), requesting qawanted to verify.

Comment 17

[Brogan Zumwalt [Inactive]]

Issue verified fixed on Flame 3.0

Lockscreen passcode can be entered without duplicate inputs, as can adding smart collections and toggling options in Developer Menu. User can answer inbound calls without difficulty.

Device: Flame 3.0 Master
BuildID: 20150202154235
Gaia: 4171327fce4803c52b2fae8071b114a70a3a68a7
Gecko: 3bf7ed413e87
Version: 38.0a1 (3.0 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Comment 18

[Johan Lorenzo [:jlorenzo]]

Moving the bug to the component where the regression came from.