Closed
Bug 1129210
Opened 11 years ago
Closed 11 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•11 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regression
Whiteboard: [3.0-Daily-Testing]
![]() |
||
Comment 1•11 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•11 years ago
|
QA Contact: pcheng
![]() |
||
Comment 2•11 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•11 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•11 years ago
|
||
![]() |
||
Comment 5•11 years ago
|
||
![]() |
||
Updated•11 years ago
|
QA Contact: pcheng
Comment 6•11 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•11 years ago
|
Assignee: nobody → mchang
Status: NEW → ASSIGNED
Flags: needinfo?(mchang)
![]() |
Assignee | |
Comment 7•11 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•11 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•11 years ago
|
||
![]() |
||
Comment 10•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
status-firefox38:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
![]() |
Assignee | |
Comment 11•11 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•11 years ago
|
blocking-b2g: 3.0? → 2.2+
Updated•11 years ago
|
Attachment #8559441 -
Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
![]() |
||
Comment 12•11 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•11 years ago
|
||
![]() |
Assignee | |
Comment 14•11 years ago
|
||
Hmm, bug 1062331 was uplifted before this. Ryan, can we please uplift this? Thanks!
Flags: needinfo?(ryanvm)
Comment 15•11 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•11 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•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/20611af1c1a4
Thanks for the ping :)
![]() |
||
Comment 18•11 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•11 years ago
|
||
![]() |
||
Updated•11 years ago
|
QA Whiteboard: [MGSEI-Triage+]
You need to log in
before you can comment on or make changes to this bug.
Description
•