[Homescreen] Active Scrolling then pausing will leave phone without scroll/section until Tap Off

RESOLVED FIXED in Firefox 38, Firefox OS v2.2

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: onelson, Assigned: mchang)

Tracking

({regression})

unspecified
mozilla38
ARM
Gonk (Firefox OS)
regression
Points:
---

Firefox Tracking Flags

(blocking-b2g:2.2+, firefox36 wontfix, firefox37 wontfix, firefox38 fixed, b2g-v2.2 verified, b2g-master verified)

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(6 attachments)

(Reporter)

Description

4 years ago
Created attachment 8558802 [details]
logcat_20150203_1552.txt

Description:
When a user is scrolling on the homescreen, they will observe that if they keep their finger held on the screen but pause for a brief moment, that scrolling will be broken and no selections can be made until the user releases their hold/tap on the phone.

Repro Steps:
1) Update a Flame to 20150203055641
2) Hold tap and scroll up and down.
3) Persist tap and stop scrolling for 2~ seconds.
4) Persist tap and begin scrolling.

Actual:
Scrolling will not continue until the user releases their initial hold on the homescreen and attempts again.

Expected:
Scrolling can continue on the same user depression for the length of the hold.


Environmental Variables:
--------------------------------------------------
Device: Flame 3.0
Build ID: 20150203055641
Gaia: ae5a1580da948c3b9f93528146b007fc4f6a712b
Gecko: ae5d04409cd9
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

--------------------------------------------------
Issue DOES NOT REPRO on flame 2.2 devices:
Results: Scrolling can continue on the same user depression for the length of the hold.

Device: Flame 2.2
BuildID: 20150203002504
Gaia: cd62ff9fe199fb43920ba27bd5fdbc5c311016fc
Gecko: 11d93135c678
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
--------------------------------------------------

Repro frequency: 5/5
See attached: 
video- http://youtu.be/C4hLVETZO34 
logcat
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
[Blocking Requested - why for this release]:
Functional regression of a core feature.

Requesting a window.
blocking-b2g: --- → 3.0?
QA Whiteboard: [QAnalyst-Triage?]
Component: Gaia::Homescreen → Panning and Zooming
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
Product: Firefox OS → Core
QA Contact: pcheng
regression window:

Last Working build - issue does NOT repro
20150202042034

First Broken build - issue DOES repro
20150202142919

First Broken Gaia & Last Working Gecko - issue DOES repro
Build ID               20150202142919
Gaia Revision          4171327fce4803c52b2fae8071b114a70a3a68a7
Gaia Date              2015-02-02 06:06:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7c87286ce969
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150203.041704
Firmware Date          Tue Feb  3 04:17:15 EST 2015
Bootloader             L1TC000118D0

First Broken Gecko & Last Working Gaia - issue does NOT repro
Build ID               20150202042034
Gaia Revision          ae5a1580da948c3b9f93528146b007fc4f6a712b
Gaia Date              2015-02-02 19:50:21
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3bf7ed413e87
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20140923.200317
Firmware Date          Tue Sep 23 20:03:27 EDT 2014
Bootloader             L1TC000118D0
Keywords: regressionwindow-wanted
Sorry to update:

First Broken Gecko & Last Working Gaia - issue DOES repro
Build ID               20150202142919
Gaia Revision          4171327fce4803c52b2fae8071b114a70a3a68a7
Gaia Date              2015-02-02 06:06:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7c87286ce969
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150203.041704
Firmware Date          Tue Feb  3 04:17:15 EST 2015
Bootloader             L1TC000118D0

First Broken Gaia & Last Working Gecko - issue does NOT repro
Build ID               20150202042034
Gaia Revision          ae5a1580da948c3b9f93528146b007fc4f6a712b
Gaia Date              2015-02-02 19:50:21
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3bf7ed413e87
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20140923.200317
Firmware Date          Tue Sep 23 20:03:27 EDT 2014
Bootloader             L1TC000118D0
Created attachment 8559051 [details]
First Broken Gecko&Last Working Gaia.MP4
QA Contact: pcheng
I was able to reproduce this, and investigated it. The problem seems to be related to vsync / touch dispatching. Specifically, here's what I found:

  - When I'm initially panning, touch-moves get to GeckoTouchDispatcher::NotifyTouch.
    They are not dispatched right away, but added to the mTouchMoveEvents vector.

  - Periodically, GeckoTouchDispatcher::NotifyVsync is called, and dispatches
    touch-move events based on the ones stored in the vector. The dispatched touch
    events then make it to APZ and content.

  - When I pause during my pan, after a sufficiently long pause, NotifyVsync stops
    getting called.

  - When I then move my finger again, NotifyTouch continues getting toich-moves and
    placing them into the vector, but since NotifyVsync is no longer being called,
    nothing is triggering their dispatch, and so they don't make it to APZ and 
    content.

I'm not very familiar with how NotifyVsync works / who is supposed to be calling it. Mason, this is more your domain - do you think you could have a look?
Flags: needinfo?(mchang)
(Assignee)

Updated

4 years ago
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Flags: needinfo?(mchang)
(Assignee)

Updated

4 years ago
Blocks: 1062331
(Assignee)

Comment 7

4 years ago
Created attachment 8559441 [details] [diff] [review]
Always enable vsync when touch events occur

(In reply to Botond Ballo [:botond] from comment #6)
> I was able to reproduce this, and investigated it. The problem seems to be
> related to vsync / touch dispatching. Specifically, here's what I found:
> 
>   - When I'm initially panning, touch-moves get to
> GeckoTouchDispatcher::NotifyTouch.
>     They are not dispatched right away, but added to the mTouchMoveEvents
> vector.
> 
>   - Periodically, GeckoTouchDispatcher::NotifyVsync is called, and dispatches
>     touch-move events based on the ones stored in the vector. The dispatched
> touch
>     events then make it to APZ and content.
> 
>   - When I pause during my pan, after a sufficiently long pause, NotifyVsync
> stops
>     getting called.
> 
>   - When I then move my finger again, NotifyTouch continues getting
> toich-moves and
>     placing them into the vector, but since NotifyVsync is no longer being
> called,
>     nothing is triggering their dispatch, and so they don't make it to APZ
> and 
>     content.
> 
> I'm not very familiar with how NotifyVsync works / who is supposed to be
> calling it. Mason, this is more your domain - do you think you could have a
> look?

Thanks Botond for investigating this far, it made it really easy to find the bug! The problem is that while a finger is paused, we stop compositing. After enough time, we disable vsync to save power. When we start moving a finger again, we don't re-enable vsync because we only enabled vsync on touch starts. This patch keeps vsync alive and enabled as long as touch events are coming in.
Attachment #8559441 - Flags: review?(bugmail.mozilla)
Comment on attachment 8559441 [details] [diff] [review]
Always enable vsync when touch events occur

Review of attachment 8559441 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the quick investigation and patch, guys!
Attachment #8559441 - Flags: review?(bugmail.mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/ab5183734da9
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox38: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
(Assignee)

Comment 11

4 years ago
Comment on attachment 8559441 [details] [diff] [review]
Always enable vsync when touch events occur

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Project Silk, bug 1118530.
User impact if declined: This bug will occur and the user cannot scroll until a touch start begins.
Testing completed: Manual testing to verify the bug fix.
Risk to taking this patch (and alternatives if risky): Low - This bug occurred due to shutting off vsync in incorrect situations. 
String or UUID changes made by this patch: None
Attachment #8559441 - Flags: approval-mozilla-b2g37?

Updated

4 years ago
blocking-b2g: 3.0? → 2.2+
status-b2g-master: affected → fixed

Updated

4 years ago
Attachment #8559441 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
This bug has been successfully verified on latest Flame v3.0.
See attachment: verified_v3.0.mp4
Reproduce rate: 0/5

Flame 3.0 build:
Build ID               20150208010208
Gaia Revision          994896b89ba10cad39a87f90eeaba9ae5e17c3a6
Gaia Date              2015-02-07 19:22:02
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/be65d1fde126
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150208.050436
Firmware Date          Sun Feb  8 05:04:47 EST 2015
Bootloader             L1TC000118D0
status-b2g-master: fixed → verified
(Assignee)

Comment 14

4 years ago
Hmm, bug 1062331 was uplifted before this. Ryan, can we please uplift this? Thanks!
Flags: needinfo?(ryanvm)
Yeah, this would have been uplifted earlier, but the unaffected status flag made it invisible to the usual bug queries. Please double-check those for accuracy in the future?
status-b2g-v2.2: unaffected → affected
status-firefox36: --- → wontfix
status-firefox37: --- → wontfix
Flags: needinfo?(ryanvm)
(Assignee)

Comment 16

4 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #15)
> Yeah, this would have been uplifted earlier, but the unaffected status flag
> made it invisible to the usual bug queries. Please double-check those for
> accuracy in the future?

Ahh will do, thanks for the heads up.
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/20611af1c1a4

Thanks for the ping :)
status-b2g-v2.2: affected → fixed
Per Comment 15 and Comment 17, this bug has been verified successfully on the latest Flame v2.2.
See attachment: verified_v2.2.mp4.
Reproduce rate: 0/5.

Flame 2.2 build:
Build ID               20150303002527
Gaia Revision          3d188c414e30acc392253d5389a42352fcfbc183
Gaia Date              2015-03-03 00:53:42
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c89aad487aa5
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150303.034757
Firmware Date          Tue Mar  3 03:48:06 EST 2015
Bootloader             L1TC000118D0
status-b2g-v2.2: fixed → verified
QA Whiteboard: [MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.