Closed Bug 1050470 Opened 6 years ago Closed 6 years ago

touch events not opening apps while scroll is ending

Categories

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

x86
macOS
defect
Not set

Tracking

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

VERIFIED FIXED
2.1 S3 (29aug)
blocking-b2g 2.0+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: dietrich, Assigned: crdlc)

References

Details

(Keywords: regression)

Attachments

(2 files)

I've noticed lately that I am constantly touching an icon on the homescreen, and the app doesn't open. It takes 1-2 more tries to work.

I am not completely sure, but it *feels* like what's happening is that I scroll to get the app icon into the viewport, and then touch the icon and the scroll has not quite completed yet due to inertial scrolling.

Flame, master.
QA Wanted for branch checks.
Keywords: qawanted
QA Contact: ckreinbring
The bug repros on Flame 2.1, Flame 2.0, and Buri 2.1
Actual result: If the user taps an app icon after the screen stops scrolling but before the slider bar fades out the tap will not be acknowledged.  On 2.1 the first tap after the bar fades out may not be acknowledged.

Flame 2.1
BuildID: 20140808091209
Gaia: c97d1b6c3094e854377b6affa5f46b8d4b7316ce
Gecko: f40c3647561c
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0
BuildID: 20140808063734
Gaia: 4c8c6569f2fded3c610cb6baf2e86355b1004653
Gecko: 1a895eb2b312
Platform Version: 32.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.1
BuildID: 20140808091209
Gaia: c97d1b6c3094e854377b6affa5f46b8d4b7316ce
Gecko: f40c3647561c
Platform Version: 34.0a1
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

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

The bug does not repro on Flame 1.4
Actual result: The homescreen is the pre-vertical homescreen interface, so the icons can be tapped immediately after the page is changed.

BuildID: 20140808033135
Gaia: 2b2849a61cd38e909ed1c3e4586d104bc96f7001
Gecko: 931bf8651711
Platform Version: 30.0
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Josh - Can you provide a blocking triage analysis?
Flags: needinfo?(jmitchell)
[Blocking Requested - why for this release]:frustrating user experience
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Regression window
Last working
BuildID: 20140731150609
Gaia: 04ea7e1a4034a50d4a7a4f5b95a04a2ed8313908
Gecko: 104254bd1fc8
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken
BuildID: 20140801070614
Gaia: 9689218473b6fc4dd927ad6aa7b06c05f0843824
Gecko: 8970589d6505
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Working Gaia / Broken Gecko = No repro
Gaia: 04ea7e1a4034a50d4a7a4f5b95a04a2ed8313908
Gecko: 8970589d6505
Broken Gaia / Working Gecko = Repro
Gaia: 9689218473b6fc4dd927ad6aa7b06c05f0843824
Gecko: 104254bd1fc8
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/04ea7e1a4034a50d4a7a4f5b95a04a2ed8313908...9689218473b6fc4dd927ad6aa7b06c05f0843824


B2G-inbound
Last working
BuildID: 20140731221511
Gaia: bc16638fff952754efbdfd6f84b8e068c12b4f6f
Gecko: 7f5777fa92be
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken
BuildID: 20140731232712
Gaia: 87ffc8423953bf052ed2b953c7f5e0133cbf1384
Gecko: 00309d08d723
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Working Gaia / Broken Gecko = No repro
Gaia: bc16638fff952754efbdfd6f84b8e068c12b4f6f
Gecko: 00309d08d723
Broken Gaia / Working Gecko = Repro
Gaia: 87ffc8423953bf052ed2b953c7f5e0133cbf1384
Gecko: 7f5777fa92be
Gecko pushlog: https://github.com/mozilla-b2g/gaia/compare/bc16638fff952754efbdfd6f84b8e068c12b4f6f...87ffc8423953bf052ed2b953c7f5e0133cbf1384
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by bug 1043293 ? Julien - can you take a look?
Blocks: 1043293
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(felash)
I think we can dupe to bug 1043834. I have a WIP there that should be able to be finished easily if it's made a blocker.

I wasn't aware it was working before my patch in bug 1043293, I even think I tried this... So sorry about this.

Won't be able to work on it though because I'm in holidays starting... now :)
Flags: needinfo?(felash)
blocking-b2g: 2.0? → 2.0+
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Assignee: nobody → crdlc
Status: NEW → ASSIGNED
I don't really think this is something we should try to fight in gaia. If you touch the screen during a scroll, we stop the scroll - that's how it's supposed to be.

If we want to fix this then I think we should re-visit APZ physics/implementation.
I was actually noticing this as well and it didn't feel like the APZ stop-scroll-on-tap so I took a look, and indeed it seems to be caused by something else. Digging around in the gaia code I see that there is still a 300ms prevent-tap timeout [1] which is probably causing this. Logging in gecko seems to confirm this (i.e. on clicks where the icon actually triggers I see the touchend event get prevent-defaulted and on clicks where the icon doesn't trigger it seems like the click event is dispatched but has no effect). The gaia code should probably be removed now that the APZ will consume taps to stop scrolls.

[1] https://github.com/mozilla-b2g/gaia/blob/8931e4f5e905bd7c33209384b9ff0087a580df17/shared/elements/gaia_grid/js/grid_view.js#L12
Thanks for weighing in and doing the investigation Kats! Let's remove the hack if we want to fix this. Sound good to you Cristian?
Attached file Github pull request
Attachment #8476486 - Flags: review?(kgrandon)
Comment on attachment 8476486 [details]
Github pull request

Seems to work fine for me, thanks! Left a comment on github - not sure if we still need that code or not.
Attachment #8476486 - Flags: review?(kgrandon) → review+
Merged in master:

https://github.com/mozilla-b2g/gaia/commit/60d4abc585559f0936108f4617ddac2df3a6e3df
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Blocks: 1062527
This issue has been verified successfully on Flame2.0&2.1&2.2
Verify video:"verify_1050470.mp4".
**From comment 2
 "If the user taps an app icon after the screen stops scrolling but before the slider bar fades out the tap will not be acknowledged"
we could see we should tap the icon after slide bar disappeared? 

Flame2.0 build
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141201000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034308
FW-Date         Mon Dec  1 03:43:18 EST 2014

Flame2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034405
FW-Date         Mon Dec  1 03:44:15 EST 2014
Bootloader      L1TC00011880
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.