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

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[James Willcox (:snorp) ([e-mail]) (he/him)]

Seems to be worse near tip of page. Using Nightly.

Comment 1

[Benoit Girard (:BenWa)]

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.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

Attachment: Profile while panning

Looks like it's painting full-tilt for some reason, and the compositor is bogged down with the layer transactions.

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

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).

Comment 4

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8659005 [details]
Profile while panning

I had something hosed up in my environment when I took this, ignore

Comment 6

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 7

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

[Kartikaya Gupta (email:[e-mail])]

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?

Comment 9

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 10

[James Willcox (:snorp) ([e-mail]) (he/him)]

[Tracking Requested - why for this release]:

Comment 11

[Kartikaya Gupta (email:[e-mail])]

(In reply to James Willcox (:snorp) ([e-mail]) 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.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 43+. Is it safe to assume this also affects 44?  
Can you help find an owner for this bug?

Comment 13

[Milan Sreckovic [:milan] (needinfo for best results)]

:snorp, why track?  That bad, especially given comment 11?

Comment 14

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)
> (In reply to James Willcox (:snorp) ([e-mail]) 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...

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

comment #14

Comment 16

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 17

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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!

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

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

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 20

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Kartikaya Gupta (email:[e-mail]) 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

[Sylvestre Ledru [:Sylvestre]]

Not tracking (cf comment #19)

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Works fine with APZ, closing.