Open Bug 1738126 Opened 2 years ago Updated 2 years ago

weird scrolling issue for firefox

Categories

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

Unspecified
Android
defect

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox93 --- unaffected
firefox94 --- unaffected
firefox95 --- disabled
firefox96 --- disabled

People

(Reporter: mcomella, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

The user who filed this in GitHub suggested this is a regression from bug 1731120.

Regressed by: 1731120

That'd be an odd regression range, but maybe?

Flags: needinfo?(jfkthame)

Seems to work fine in responsive design mode (with user agent etc set so that I get the mobile website that matches the videos).

Interestingly, I see a similar issue on the site's desktop version: if I simply load https://www.milliyet.com.tr/ in Nightly, I get a page with a wide carousel of (presumably) "top stories" across the middle; these can be scrolled left/right with the mouse, or will auto-cycle if left alone; they also scroll in response to hovering over the five small squares (for each of the five items in the carousel) on the left. These scroll operations -- whichever way they're triggered -- are quite rough/jerky, similar to the reporter's video from mobile.

Trying the same site in release Firefox, I see much smoother scrolling. So I was going to try and use mozregression to narrow down a regression range and see if it matched the report; but when running mozregression, I get smooth scrolling in all builds. Which suggests something about my Nightly profile may be affecting it, although I'm not sure what...

When it's in the "bad" state, there's a lot of whitespace above the top-stories carousel; inspecting this, I find a div with <div id="9927946/milliyet/anasayfa/header_728x90_masthead" class="adRenderer dfp mb30 dfp_masthead adCls-250" data-device-type="desktop"> that contains some kind of Google Ads script. If I style this div with display: none, so that the excess whitespace disappears, scrolling becomes smooth. Curiously, sometimes when the page loads in a "good" state, this div gets hidden by some script that runs shortly after load: I see the whitespace initially, and then it disappears, and watching in devtools I see the inline display: none style get added. But in some cases I get smooth scrolling even though this ad space is still present, so the overall issue is more complex than that.

Overall, I suspect the issue here is somehow related to all the tracking/advertising content on the page, and unlikely to really be a regression from bug 1731120. But I don't know exactly what's causing it...

Oh, here's another odd thing: the behavior appears to depend on the scroll position of the overall page! When I load the page in Nightly, I see the bad (jerky) scrolling of the carousel; but if I scroll the page by a couple of inches so that the carousel is at the top of the window, it now scrolls smoothly from side to side. Scroll it back down, and the jerky behavior returns.

Flags: needinfo?(jfkthame)

Recording showing the contrast between "jerky" and "smooth" scrolling of the carousel, in Nightly on desktop macOS.

(In reply to Jonathan Kew (:jfkthame) from comment #5)

Created attachment 9248201 [details]
Screen Recording 2021-10-28 at 10.03.34.mov

Recording showing the contrast between "jerky" and "smooth" scrolling of the carousel, in Nightly on desktop macOS.

I can reproduce the "jerky" and "smooth" scrolling of the carousel in Nightly95.0a1 Windows10.

Regression window the "jerky":
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c36cad76a78d33eb219513bf2117c1d72c6e1d65&tochange=0a92348ed33532d65fffbfd9a8028220c2e5fc06

Set release status flags based on info from the regressing bug 1731120

To me, it's a faulting case of the partial pre-render (bug 1659227), it's not enabled on beta/release channels.

Severity: -- → S3
Regressed by: 1659227
Has Regression Range: --- → yes
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.