Closed
Bug 1203349
Opened 9 years ago
Closed 8 years ago
Flinging down when urlbar is shown sometimes stops immediately instead of scrolling the page
Categories
(Firefox for Android Graveyard :: Toolbar, defect)
Tracking
(firefox43+ wontfix, firefox44+ wontfix, firefox45- affected)
RESOLVED
FIXED
Firefox 48
People
(Reporter: snorp, Unassigned)
References
()
Details
(Whiteboard: [gfx-noted])
Attachments
(1 obsolete file)
Seems to be worse near tip of page. Using Nightly.
Comment 1•9 years ago
|
||
I've noticed panning on Fennec has been very jerky as well. It would be nice if we could get a profile and a regression-window. But it's possible it slowly got worse so we might not have a clear offending changeset if we bisect.
Reporter | ||
Comment 2•9 years ago
|
||
Looks like it's painting full-tilt for some reason, and the compositor is bogged down with the layer transactions.
Reporter | ||
Comment 3•9 years ago
|
||
Looking a little closer, the compositor appears to be constantly receiving tile transactions (spending nearly all of its time in PLayerTransaction::RecvUpdateNoSwap()), but the main thread does not appear to be sending the transactions (all of its time in Wait).
Reporter | ||
Comment 4•9 years ago
|
||
Eh, that profile is kinda bogus. It is doing paints, they're just too fast for the profiler to catch it I guess. The reason this is slow is because we're falling into the synchronous scroll path. It doesn't seem obvious from the content on the page, but gdb shows we're scrolling the body .scrollTop from a 'Gesture:Scroll' event, which is the synchronous iframe garbage.
Depends on: apz-fennec
Reporter | ||
Comment 5•9 years ago
|
||
Comment on attachment 8659005 [details]
Profile while panning
I had something hosed up in my environment when I took this, ignore
Attachment #8659005 -
Attachment is obsolete: true
Reporter | ||
Comment 6•9 years ago
|
||
I think the viewport change when we hide the urlbar is causing some badness here. I don't know if it's confusing the java APZ or what. It would cause a reflow, but I'm not sure why that would hose the APZ/Compositor.
Flags: needinfo?(bugmail.mozilla)
Reporter | ||
Comment 7•9 years ago
|
||
Disabling the dynamic toolbar doesn't appear to help. Now wondering if there are touch event listeners in the page fouling things up...
Comment 8•9 years ago
|
||
We do send more resizes with the dynamic toolbar now than we did before. If the page is doing something dumb like registering a new listener every time it gets a resize event it could bog things down over time. But if you're seeing it with the dynamic toolbar disabled as well then it can't be that. Can you get a new profile now that your environment is un-hosed?
Flags: needinfo?(bugmail.mozilla)
Updated•9 years ago
|
Whiteboard: [gfx-noted]
Reporter | ||
Comment 9•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #8) > We do send more resizes with the dynamic toolbar now than we did before. If > the page is doing something dumb like registering a new listener every time > it gets a resize event it could bog things down over time. But if you're > seeing it with the dynamic toolbar disabled as well then it can't be that. > Can you get a new profile now that your environment is un-hosed? There seem to be at least two different problems here: 1) The first problem is that when flinging from the top, JPZC seems to interrupt the animation right away and you just end up with the urlbar hidden. 2) The page is getting into synchronous scrolling mode somehow (I guess the content is in a scrollable div). I think maybe we can just morph this bug to deal with case 1, since 2 is pretty well covered.
Summary: Panning yahoo news is slow on Fennec → Flinging down when urlbar is shown sometimes stops immediately instead of scrolling the page
Reporter | ||
Comment 10•9 years ago
|
||
[Tracking Requested - why for this release]:
tracking-firefox43:
--- → ?
Comment 11•9 years ago
|
||
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #9) > 1) The first problem is that when flinging from the top, JPZC seems to > interrupt the animation right away and you just end up with the urlbar > hidden. When you do this fling, does your finger lift off the screen before or after the urlbar is hidden? If the former, then it's not a JPZC problem, it's just an artifact of the new dynamic toolbar code. The JPZC doesn't even see the touch events that the dynamic toolbar consumes, so if you start at the top of the page and move your finger by Y pixels (where Y is less than the dynamic toolbar height) then all of that movement gets consumed by the toolbar hiding, and nothing goes to the JPZC. Hence no fling. If your finger is on the screen until after the urlbar is hidden then yes it may be a JPZC problem.
Updated•9 years ago
|
Component: Graphics → Graphics, Panning and Zooming
Product: Core → Firefox for Android
Comment 12•9 years ago
|
||
Tracking for 43+. Is it safe to assume this also affects 44? Can you help find an owner for this bug?
status-firefox43:
--- → affected
status-firefox44:
--- → affected
tracking-firefox44:
--- → +
Flags: needinfo?(snorp)
:snorp, why track? That bad, especially given comment 11?
Reporter | ||
Comment 14•9 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11) > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #9) > > 1) The first problem is that when flinging from the top, JPZC seems to > > interrupt the animation right away and you just end up with the urlbar > > hidden. > > When you do this fling, does your finger lift off the screen before or after > the urlbar is hidden? If the former, then it's not a JPZC problem, it's just > an artifact of the new dynamic toolbar code. The JPZC doesn't even see the > touch events that the dynamic toolbar consumes, so if you start at the top > of the page and move your finger by Y pixels (where Y is less than the > dynamic toolbar height) then all of that movement gets consumed by the > toolbar hiding, and nothing goes to the JPZC. Hence no fling. > > If your finger is on the screen until after the urlbar is hidden then yes it > may be a JPZC problem. Yeah, it's possible my finger was off the screen when the urlbar was still in the process of hiding. I think we need to pass the velocity to the PZC somehow in order to avoid this. A fling from the top of the screen is a common operation...
Flags: needinfo?(snorp)
Comment 16•9 years ago
|
||
Ok. To do this right we'd have to pass the touch events themselves through because we need to allow content to preventDefault them. If we only passed the velocity through then we might trigger a fling when content would have cancelled it. I'll add this to my pile of things to look into.
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
Kats: I am just trying to review the bugs marked tracking for FF44. This bug hasn't had much activity in the past 4 weeks. Is there a patch in the works that you want to uplift to Aurora44? If we don't have plans to fix this for FF44, please feel free to update status-firefox44 to wontfix. Thanks!
Flags: needinfo?(bugmail.mozilla)
Comment 18•9 years ago
|
||
Too late for 43 at this point but we could likely still take a patch for 44 if this is a bad problem in 44 beta.
Comment 19•9 years ago
|
||
I just spent some time looking into this a bit more - seems like the behaviour is specific to yahoo news, and it only happens when you're at the top of the page with the URL bar shown. If you're halfway down with the URL bar shown then it works fine. Also, this (on yahoo news at least) doesn't appear to be a regression, I can reproduce it on current release Firefox (42.0.1) as well. It doesn't happen on the first fling but if you go back to the top it happens every time after that. It does appear to be mostly fixed by the C++ APZ though, so I imagine it's a problem that's a combination of subframe scrolling and what the page is doing. Based on it not really being a regression I'm not planning on fixing it 44.
Assignee: bugmail.mozilla → nobody
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19) > Based on it not really being a regression I'm not planning on fixing it 44. Sounds good to me. Thanks!
Comment 21•9 years ago
|
||
Not tracking (cf comment #19)
Comment 22•8 years ago
|
||
Works fine with APZ, closing.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•