Flinging down when urlbar is shown sometimes stops immediately instead of scrolling the page

RESOLVED FIXED in Firefox 48

Status

()

Firefox for Android
Toolbar
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: snorp, Unassigned)

Tracking

unspecified
Firefox 48
ARM
Android
Points:
---

Firefox Tracking Flags

(firefox43+ wontfix, firefox44+ wontfix, firefox45- affected)

Details

(Whiteboard: [gfx-noted], URL)

Attachments

(1 obsolete attachment)

Seems to be worse near tip of page. Using Nightly.
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.
Created attachment 8659005 [details]
Profile while panning

Looks like it's painting full-tilt for some reason, and the compositor is bogged down with the layer transactions.
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).
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: 776030
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
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)
Disabling the dynamic toolbar doesn't appear to help. Now wondering if there are touch event listeners in the page fouling things up...
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)
Whiteboard: [gfx-noted]
(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
[Tracking Requested - why for this release]:
tracking-firefox43: --- → ?
(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.
Component: Graphics → Graphics, Panning and Zooming
Product: Core → Firefox for Android
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-firefox43: ? → +
tracking-firefox44: --- → +
Flags: needinfo?(snorp)
:snorp, why track?  That bad, especially given comment 11?
(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 #14
Flags: needinfo?(bugmail.mozilla)
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)
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.
status-firefox43: affected → wontfix
status-firefox45: --- → ?
tracking-firefox45: --- → ?
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
status-firefox44: affected → wontfix
Depends on: 1206874
No longer depends on: 776030
Flags: needinfo?(bugmail.mozilla)
See Also: → bug 1230078
(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!
Not tracking (cf comment #19)
status-firefox45: ? → affected
tracking-firefox45: ? → -
Works fine with APZ, closing.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
You need to log in before you can comment on or make changes to this bug.