1653042 - header at foxnews.com repeatedly disappears & drifts into view, each time I use mouse/trackpad to scroll downwards

Status: NEW

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Visit https://www.foxnews.com/politics/oklahomas-kevin-stitt-becomes-first-governor-to-test-positive-for-coronavirus (or probably any foxnews.com article that has a "Coronavirus pandemic" heading-banner near the top of the page)

2. Scroll down far enough so that the "Coronavirus Pandemic" header hits the top of the page.

3. Scroll down a single "tick" (or more) using your mousewheel or a touchpad gesture. Repeat. Also try scrolling back up one "tick" (which correctly prompts the header to reappear), and then down again.

ACTUAL RESULTS:
When I've scrolled down far enough so that the "Coronavirus Pandemic" banner hits the top of the screen, then nearly every subsequent mousewheel/touchpad-scroll action seems to trigger this behavior:

• The banner smooth-scrolls partway-entirely off the top of viewport (as exected)
• ...but suddenly, banner reappears.
• This happens on almost every scroll, which feels quite jarring.
• Also: the article text seems to jiggle down slightly (the wrong direction) at some point during the scroll operation.

EXPECTED RESULTS:

• Article text should not jiggle the wrong direction on scroll actions.
• Banner should not reappear on scrolling-down-the-page actions (not unless I actually scroll back upwards)

Chrome gives EXPECTED RESULTS.
If I use keyboard scrolling instead of mousewheel/touchpad scrolling, then I also see EXPECTED RESULTS in Firefox. This is specifically a problem with mousewheel/touchpad scrolling.

Note: I can work around this by setting about:config pref general.smoothScroll to false, but that's not the whole story (i.e. this isn't just a smoothScroll bug), because the keyboard-arrow-scrolling does "smooth scroll" too and it doesn't have any problems.

(Not sure if this is an APZ vs. Layout:Scrolling/Overflow bug; feel free to reclassify as appropriate.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast, showing me mousewheel scrolling down the page 4 "ticks"

Here's a screencast of the bug, showing 4 "ticks" of mousewheel scrolling down the page. On two of the ticks, the banner disappears (as expected); on the other two, the banner appears (unexpectedly/unwanted).

And after the very last scroll operation, you can see that the article text is jiggling up and down (unexpectedly).

Comment 2

[Daniel Holbert [:dholbert]]

Profile of me scrolling on this page: https://share.firefox.dev/2CD4v0B
In this profile, I had six "single-wheel-tick" mousewheel-scroll operations (visible as bursts of activity in the profile). The fourth and sixth operations are the ones that happened to have this problem (where the header suddenly appeared after the scroll operation completed), as you can see in the screenshots track.

Here's a zoomed in view of the fourth scroll operation: https://share.firefox.dev/30dyWlV
and a zoomed-in view of the sixth: https://share.firefox.dev/30gC8x5

Comment 3

[Daniel Holbert [:dholbert]]

Also worth noting: this bug happens regardless of whether you have scroll anchoring enabled, so it's not related to scroll anchoring.

Comment 4

[Botond Ballo [:botond]]

The header in question is being toggled between position: fixed and position: relative by script on the page, so I think the next step here is to investigate which event listener is triggering that script, and where in the script (or in which event listener is triggered) the difference between Firefox and Chrome originates.

Comment 5

[Jonathan Kew [:jfkthame]]

FWIW, I can confirm I see this on macOS as well. Interestingly, I'm also seeing similar glitchiness when scrolling down on that page in Safari, including (very occasionally) when using the down-arrow key to scroll, not just the trackpad. It seems less prevalent than in Firefox, but looks like the same issue of the header sometimes getting flipped back to position:fixed on a scroll-down where it's supposed to stay relative.

Could this be triggered by rounding of y-offsets at some level, such that the page's JS is mistakenly thinking there was a tiny scroll-up action after the scroll-down (as things are adjusted to integer-pixel locations, maybe)? This is pure speculation, but that's kinda how it feels...