Closed
Bug 1129210
Opened 9 years ago
Closed 9 years ago
[Homescreen] Active Scrolling then pausing will leave phone without scroll/section until Tap Off
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
People
(Reporter: onelson, Assigned: mchang)
References
()
Details
(Keywords: regression, Whiteboard: [3.0-Daily-Testing])
Attachments
(6 files)
110.53 KB,
text/plain
|
Details | |
234.58 KB,
text/plain
|
Details | |
3.08 MB,
video/mp4
|
Details | |
991 bytes,
patch
|
kats
:
review+
bajaj
:
approval-mozilla-b2g37+
|
Details | Diff | Splinter Review |
5.29 MB,
video/mp4
|
Details | |
5.44 MB,
video/mp4
|
Details |
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•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
Comment 1•9 years ago
|
||
[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
Updated•9 years ago
|
QA Contact: pcheng
Comment 2•9 years ago
|
||
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
Comment 3•9 years ago
|
||
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
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
Updated•9 years ago
|
QA Contact: pcheng
Comment 6•9 years ago
|
||
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•9 years ago
|
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Flags: needinfo?(mchang)
Assignee | ||
Comment 7•9 years ago
|
||
(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 8•9 years ago
|
||
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+
Assignee | ||
Comment 9•9 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/ab5183734da9
Comment 10•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ab5183734da9
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox38:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
Assignee | ||
Comment 11•9 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•9 years ago
|
blocking-b2g: 3.0? → 2.2+
Updated•9 years ago
|
Attachment #8559441 -
Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Comment 12•9 years ago
|
||
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
Comment 13•9 years ago
|
||
Assignee | ||
Comment 14•9 years ago
|
||
Hmm, bug 1062331 was uplifted before this. Ryan, can we please uplift this? Thanks!
Flags: needinfo?(ryanvm)
Comment 15•9 years ago
|
||
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?
Assignee | ||
Comment 16•9 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.
Comment 17•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/20611af1c1a4 Thanks for the ping :)
Comment 18•9 years ago
|
||
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
Comment 19•9 years ago
|
||
Updated•9 years ago
|
QA Whiteboard: [MGSEI-Triage+]
You need to log in
before you can comment on or make changes to this bug.
Description
•