1103394 - When scrolling Twitter across transition-threshold between small profile-photo & large one, the viewport flashes a mis-scrolled view for an instant

Status: REOPENED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: screencast (bug visible at ~3s, on second scroll-up)

STR:
 1. View https://twitter.com/PrivateMe in a fairly large browser-window
    (The size matters because Twitter has different styles depending on size)
    (~1200 by 800 px works for me)

 2. Try scrolling up and down (e.g. with arrow keys) right around the point where the large profile-photo turns into a small profile photo and joins into the header-bar. Pay close attention when you scroll *up* (when the large version slides back into view)

ACTUAL RESULTS: The page flashes a mis-scrolled state as a part of this scrolling up transition.

I can reproduce in Firefox nightly; cannot reproduce in Chrome.  Happens with e10s enabled or disabled; doesn't matter.

Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Version 36.0a1 (2014-11-21)
Ubuntu 14.10 64-bit


I'm not sure if this is a layerizing/un-layerizing artifact, or if perhaps it's even "correct" given the content that Twitter serves (but Chrome skips over it for some reason).

Attached screencast shows the bug at around 3 seconds in, on my second "scroll up" attempt. (I can actually see this bug happening on nearly all of my scrolls across that threshold, but my screen-casting program isn't fast enough to capture all of the the buggy frames, so it didn't capture all the instances of the bug in this session.)

Comment 1

[Daniel Holbert [:dholbert]]

Forgot to mention:
 - You don't need to be logged into twitter (and you should dismiss the "log into twitter" popup on first pageload)

I can reproduce this in Firefox release version, too (v33), so not a regression (or not a recent one, at least).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: frame1 (scroll-up action is initiated here)

I'm going to attach a sequence of four frames, from the video, to make the bug easier to see.
 frame1 is just as I initiate the scroll-up action
 frame2 is the buggy mis-scrolled "flash"
 frame3 and frame4 are correct scrolling intermediate-points (similar to frame1, not to frame2)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: frame2 (the "flashed" mis-scrolled frame -- *way* off from frame1 and frame3)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: frame3 (correct scrolling has resumed now)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: frame4 (correct scrolling continues)

Comment 7

[Markus Stange [:mstange]]

When the header transitions from fixed ("locked") to scrolled ("unlocked"), two things happen:
 (1) The class "is-locked" is removed from the element with class "ProfileCanopy". This causes the element with class "ProfileCanopy-inner" (which is a child of .ProfileCanopy) to change from position:fixed to position:relative.
 (2) The margin-top inline style on the element with class "ProfileCanopy-header" is changed from something negative (e.g. -253px) to 0px.

(1) happens from a scroll event handler, which calls requestAnimationFrame, and the animation frame handler does (2). So if we render a frame between (1) and (2), the whole page content is moved upwards due to the negative margin that hasn't been removed yet.

Interestingly, in the reverse transition, i.e. 0px to -253px, the margin value is set directly from the scroll handler and not from the requestAnimationFrame callback.
(I found these things out using the Chrome developer tools which let you break on DOM attribute modifications.)

Comment 8

[Markus Stange [:mstange]]

Sometimes we can also get into an inconsistent state when scrolling *down*, in which the reverse is true: The header is fixed / locked, but margin-top is still 0px. In that state, the header image briefly overlaps a large part of the page. I'm not quite sure how we can get in the state, but one guess is that it happens if you quickly scroll up and then down so that two scroll events fire without an animation callback in between. Like this:

1. You start out scrolled down, in the locked state, and the header has margin-top: -253px.
2. You scroll up, which causes a transition into the unlocked state. The header becomes position:relative from inside the scroll handler, and an animation frame is requested with a callback that will set margin-top to 0px. But this callback doesn't fire yet.
3. You scroll down, which causes a transition back into the locked state. The header becomes position:fixed and margin-top is set to -253px, but it already has that value.
4. The animation frame callback fires and sets margin-top to 0px.
5. Somehow, soon after, another animation frame callback corrects the margin-top back to -253px.

I'm not sure whether steps 4 and 5 are really what's happening, but it's at least one explanation for what I'm seeing.

It's possible that this scenario can only happen with APZ, which can lead to multiple scrolls being enqueued in the event queue of the content process, which increases the chance of them being dispatched as scroll events without a refresh tick in between.

Comment 9

[Markus Stange [:mstange]]

We could ask Twitter to fix their code, or we could change the way scroll events are dispatched. For example, we could always dispatch them at the start of a refresh driver tick, such that animation frame requests from inside the scroll handler will be handled in that same refresh tick.

Comment 10

[Markus Stange [:mstange]]

By the way, both of these "flashes" also happen in Safari 9.

Comment 11

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

(In reply to Markus Stange [:mstange] from comment #9)
> We could ask Twitter to fix their code, or we could change the way scroll
> events are dispatched. For example, we could always dispatch them at the
> start of a refresh driver tick

We do this now.

> such that animation frame requests from
> inside the scroll handler will be handled in that same refresh tick.

Not sure if we do this now, though. It's worth re-testing this bug to see if it still happens.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #11)
> Not sure if we do [...] now, though. It's worth re-testing this bug to see if
> it still happens.

From a few minutes of testing, this seems to be WORKSFORME in current nightly. Tried repeating the process shown in the attached screencast over and over, and I didn't see any flashes of mis-scrolled content.  I tried in my normal browsing profile with e10s disabled, as well as in a fresh profile with e10s enabled.

Resolving as WFM.

Comment 13

[Daniel Holbert [:dholbert]]

(Nightly version in comment 12 is 46.0a1 (2016-01-05).)

Comment 14

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

Thanks!

Comment 15

[Julien Wajsberg [:julienw]]

Same for me ! Thanks for the work !

Comment 16

[Julien Wajsberg [:julienw]]

Note that in v45 it still happens though. It's likely fixed in v46 only.

Comment 17

[Julien Wajsberg [:julienw]]

Actually I see this again now.

Comment 18

[Julien Wajsberg [:julienw]]

And from mozregression this is old :/

Here is a pushlog, I couldn't make it better because builds are deleted from taskcluster:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ef94be995a453f5c464278c53478ba8c8554f81&tochange=eb25b90a05c194bfd4f498ff3ffee7440f85f1cd

Comment 19

[Julien Wajsberg [:julienw]]

Could be bug 1250550 ?

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Julien Wajsberg [:julienw] from comment #17)
> Actually I see this again now.

I can't reproduce in current Nightly, FWIW -- though I *also* can't reproduce in a Nightly from the day when I filed this (2014-11-22) launched via "mozregression --launch 2014-11-22 https://twitter.com/PrivateMe", so take my results with a grain of salt.

Maybe this bug depends on the recent content in the twitter feed in question, or some other special factor. Are you able to repro at https://twitter.com/PrivateMe ? (and/or any other specifics that might be relevant?)

Comment 21

[Julien Wajsberg [:julienw]]

Actually I think they now removed this behavior: the picture is no longer fixed on the left side after scrolling, now it just scrolls up.

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to Julien Wajsberg [:julienw] from comment #21)
> Actually I think they now removed this behavior: the picture is no longer
> fixed on the left side after scrolling, now it just scrolls up.

That just happens if your window is too skinny. If you make your window wider, you should still see the image becoming fixed as shown in the attached screencast. (That's what I still see, at least.)

Comment 23

[Julien Wajsberg [:julienw]]

Ah yes, thanks for correcting me.
So I don't repro now, but I also have a faster computer than before. I'll retry on another slower computer.

Comment 24

[MarjaE]

I am getting a similar bug in Tumblr and some other sites. The pages flashes and jumps if I try to scroll up and reach an image. And I can't really make my window any wider than my screen, so that's not a solution.

Comment 25

[MarjaE]

I filed my own bug report, but can't find it. Firefox 57 is affected, haven't tested 58. In addition to Linux, MacOS is affected. May depend on screen size-- I am using a small laptop, and reduced resolution so I can read the system text.