1159420 - [E10s][APZ] Scrolling twitter flashes the bottom part of the top image

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Will try to repro on Windows.

Comment 2

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

The page is updating the transform property on the <img> element in response to scroll events in order to implement a parallax-scrolling effect. Of course with APZ the scroll events are async from the actual scrolling so there's some lag causing the flashing effect. Not sure if there's much we can do about this without providing alternative parallax implementation mechanisms. There's some stuff in progress on that front although I'm not current on what the latest news is there.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Scroll events are dispatched using a WillPaintObserver, so they are usually async anyhow,
and those are called
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp?rev=530555a2d6d4&mark=8805-8805#8785
Should we dispatch scroll events at different time? Or detect that we have pending scroll events and
dispatch them sync before APZ does its magic?


Given that this is showing up with Twitter (among others), I think we must fix this on our side.

Do I recall correctly that Mats has been dealing with scroll event dispatching in non-apz case?
Any ideas for this bug?

Comment 4

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

What I mean is that with APZ you can scroll even if the main thread is blocked, so the scroll event that gets to content may be very delayed relative to what the user sees on screen. This just an inherent tradeoff in allowing async panning at all. Any website that attempts to reimplement fixed-position or sticky-position type behaviour using scroll events will exhibit this problem.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

And I'm saying that we can't have that problem exposed on desktop at least.
Somehow we need to inform the parent process that it needs to wait for the child to dispatch scroll 
and paint before parent can continue scrolling. Anything else would break too much web content.
Sure, it does kind of disable apz for the particular web page, but it is its problem.

How do other browsers deal with this issue?

Comment 6

[Mats Palmgren (inactive)]

Scrolling the URL works perfectly in Linux Nightly - no lag or flicker whatsoever.
Do I need to enable some pref to reproduce the problem?

Comment 7

[Mats Palmgren (inactive)]

(In reply to Olli Pettay [:smaug] from comment #3)
> Should we dispatch scroll events at different time? Or detect that we have
> pending scroll events and dispatch them sync before APZ does its magic?

I think roc can probably give you a better answer.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

e10s + layers.async-pan-zoom.enabled = true

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is a tough problem, and I've talked to Chrome devs about it a fair bit over the last few months. There's a fundamental tension between honoring what the Web developer is trying to do and providing a good user experience when what they're trying to do isn't working well.

I think first we should be conservative and if a page or element has a scroll event listener, we should disable async scrolling for that page or element. Then enabling APZ won't make things worse and will make many pages better.

Then I think we should introduce a per-page mode switch with two settings: "Page is keeping up", "page is not keeping up". If the frame rate drops below a reasonable target (e.g. 30fps over a second) we set the switch to "page is not keeping up". In that mode, we enable async scrolling no matter what (and potentially could do other things to improve the user experience by ignoring page settings). We should also fire an event to say that we've done that; obviously that event would need to be standardized. This would give developers the chance to back off and/or send telemetry. Chrome people I've talked to like this approach.

There's been discussion of an intermediate approach, a CSS property "scroll-blocks-on" which lets the author control whether they get sync or async scrolling. I hope if we do the above we won't need a property like that.

Comment 10

[Julien Wajsberg [:julienw]]

I wonder if it's really e10s related, because I see bug 1103394 both with/without e10s enabled. But maybe I'm just confused and it's a different bug?

Comment 11

[Markus Stange [:mstange]]

The fact that APZ doesn't wait on scroll handlers can lead to lag and sometimes jitter, but it shouldn't lead to the header image randomly flashing in the wrong position, which I think is what smaug filed this bug about.

I have a theory of how that "flash" happens in bug 1103394 comment 8. It's because Twitter relies on a certain ordering of scroll events and requestAnimationFrame callbacks, which is true in Chrome but not in Firefox and Safari.

Comment 12

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

smaug, are you still seeing this issue in a recent nightly? We have made some changes that should help with this.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

I don't think I've seen this particular issue very recently.

I'll open a new bug if I see similar issues.

Comment 14

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

Cool, thanks!