Closed Bug 1779404 Opened 1 year ago Closed 2 months ago

Scrolling jumps back and forth in the Facebook feed

Categories

(Core :: Panning and Zooming, defect, P2)

Product:
Core
Component:
Panning and Zooming
Version:
Firefox 102
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
120 Branch
Tracking Flags:
Tracking Status
relnote-firefox --- 119+
firefox-esr115 --- affected
firefox118 --- wontfix
firefox119 --- verified
firefox120 --- verified

People

(Reporter: resuna, Assigned: hiro)

References

Details

(Keywords: regression, webcompat:site-wait)

Attachments

(4 files)

anchorlog.txt
286.30 KB, text/plain
Details
A test case
653 bytes, text/html
Details
Bug 1779404 - Rename testing/web-platform/tests/css/css-scroll-anchoring/after-scrollable-range-shrinkage.html. r?botond
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
Details | Review
Bug 1779404 - Re-clamp the last scroll offset before updating new scroll offsets. r?botond
48 bytes, text/x-phabricator-request
dmeehan
: approval-mozilla-beta+
Details | Review

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Visit Facebook, Twitter, Reddit, or other site with an "infinite scroll" interface to their feed.

Scroll down in the feed for a few minutes.

Actual results:

The feed starts jumping back and forth several items, or scrolls down significantly and won't reliably scroll back to where you were.

This has happened on multiple sites, on two computers (Mac mini Desktop and Macbook Pro).

I may have been able to mitigate it on Facebook by closing the contacts pane which has its own scrollbar, but I could just have been imagining it.

Expected results:

Scrolling smoothly and regularly like it used to.

I don't know if multiple social media sites have simultaneously broken scrolling, but I suspect it's something in recent Firefox on Mac.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

We've improved such cases recently (bug 1692708 and bug 1692707).

Can you provide a test case? It may be bug 1740164, it's still open.

Flags: needinfo?(resuna)
See Also: → 1692707, 1692708

No, I can't provide a test case. Its something that starts happening after using a site with an "infinite scroll" interface after I've been scrolling up and down "enough".

Flags: needinfo?(resuna)

Okay, I am assuming this is a regression on Firefox 102. There's a reddit thread and there's a comment looks pretty much same as this bug.

Keywords: regression, regressionwindow-wanted

By now, this has been extensively reported on SUMO and Mozilla Connect as well. What information could help move toward a solution?

Yes, sure. If someone tries to identify which change caused this issue by using mozregression, it would be super helpful.

QA Whiteboard: [qa-regression-triage]

I see some bad scroll jumping when scrolling the facebook timeline so I tried some older builds. I can reproduce the bad scroll jumping in the following builds: 2022-01-01, 2022-03-01, 2022-04-01, 2022-07-25. This suggests that we started seeing this behaviour because of a change in the facebook website.

We've had scroll jump related issues with facebook recently (that were fixed on facebook's end) (ie bug 1768330 and related), so it's not unheard of.

Dominic, you were very helpful in getting that bug resolved, maybe you can offer some insight to this one?

Flags: needinfo?(dg)
See Also: → 1781192
See Also: → 1781145

:tnikkel it's not just Facebook. It's also other websites that use the same kind of user interface.

Support record at least 18 reports so far about this issue. See → https://trello.com/c/00RXtZB4/28-desktop-autoscroll-issue

One user confirmed that clearing Facebook cache solve the problem.

(In reply to Peter da Silva from comment #8)

:tnikkel it's not just Facebook. It's also other websites that use the same kind of user interface.

I've only ever seen the problem on facebook so I investigated that. If you want to link to specific non-facebook pages where you see this I can try to reproduce there. Alternatively if you could run https://mozilla.github.io/mozregression/ on those sites to narrow down when this started happened it would be very helpful for moving this investigation forward.

Flags: needinfo?(resuna)

(In reply to Kelimutu [:kiki] from comment #10)

One user confirmed that clearing Facebook cache solve the problem.

That tweet seems ambiguous as to whether that resolved their problem or not. Given that I can reproduce in a fresh profile on the first load of the page (when we are presumably not using cached content) I'm not sure clearing the cache is going to fix this in general.

I am guessing that the issue solved by clearing cache is autoscrolling case (e.g. bug 1781145).

I can also reproduce with layout.css.scroll-anchoring.enabled=false, so scroll anchor appears to be innocent.

I put a printf whenever a scrollframe changes scroll position. When I get one of the scroll jumps on facebook in a debug build I do not hit that printf at all, I do however hit scrollanchor asserts (which seem to be innocent given comment 14) and some reflow warnings

[Child 5041, Main Thread] WARNING: Out-of-flow frame got reflowed before its placeholder: file /Users/tim/ffpush/src/layout/generic/nsPlaceholderFrame.cpp:139

That suggests the scroll frame stays in the same spot but that the page content changes.

Okay, this video (posted in SUMO) helped me what's going on. I was actually mis-interpreting "autoscrolling" I was under the impression that it means the page scrolls smoothly.

(In reply to Timothy Nikkel (:tnikkel) from comment #15)

I put a printf whenever a scrollframe changes scroll position. When I get one of the scroll jumps on facebook in a debug build I do not hit that printf at all, I do however hit scrollanchor asserts (which seem to be innocent given comment 14) and some reflow warnings

[Child 5041, Main Thread] WARNING: Out-of-flow frame got reflowed before its placeholder: file /Users/tim/ffpush/src/layout/generic/nsPlaceholderFrame.cpp:139

That suggests the scroll frame stays in the same spot but that the page content changes.

And with this Timothy's diagnose, I believe now this is a case we fail to do scroll anchoring and I guess Facebook has changed their content's structure so that we started failing scrolling anchoring. If my guess is correct, a next step would be collecting scroll anchor log by specifying MOZ_LOG="scrollanchor:5".

For context the scroll anchor asserts that I was getting seem to happen pretty frequently on many real world websites (when nothing seems to be going wrong). So just hitting those scroll anchoring asserts doesn't necessarily mean anything is going wrong with scroll anchoring.

And I frequently get those same scroll anchor asserts while scrolling facebook and not getting any scroll jumps.

For the record they are

###!!! ASSERTION: overflow rect must include border rect, and the clamping logic here depends on that: 'overflowRect.Contains(borderRect)', file layout/generic/ScrollAnchorContainer.cpp:169

No, I don't mean that the assertion is somewhat related to this issue, what I can tell from your comment is, there's no scroll position changes but reflows happened, that means it's a probably case that we need to do scroll anchoring. In other words, we need to change the scroll position internally in response to the reflows, that's my guess.

Okay, makes sense.

I think facebook might have changed something on their end, I'm no longer able to reproduce the continual jumping seen in the video in comment 16. However, I am still able to reproduce a scroll jump of about a page height that happens while scrolling down intermittently. This is the same problem I was seeing before the last two days. If I had to hazard a guess Facebook made some change a couple days ago to cause the continual jumping and reverted or fixed it today. The less frequent jump that started before that still exists.

I uploaded a scroll anchor log when I reproduce the intermittent scroll jump. I added a printf of the form

scrollto 0x1180a41a8 from 0 32429 to 0 32511 isroot 1

in ScrollFrameHelper::ScrollToImpl, the units are appunits over 60.

You can see that I'm slowly scrolling down as the offset increases, and then the last scrollto the offset makes a jump much smaller

scrollto 0x1180a41a8 from 0 32580 to 0 28696 isroot 1

This is preceded by

[Child 6822: Main Thread]: D/scrollanchor ANCHOR(1180a43a0, https://www.facebook.com/, root: 1): Anchor has moved from -1672 to -234685.
[Child 6822: Main Thread]: D/scrollanchor ANCHOR(1180a43a0, https://www.facebook.com/, root: 1): Applying anchor adjustment of -233013 in h-ltr with anchor 119ef5010.

32580 - 233013/60 = 28696. So it appears scroll anchoring caused that jump.

Flags: needinfo?(emilio)

Emilio, does that log help you diagnose this? I can make changes and do more logging etc, it's not hard for me to reproduce.

(In reply to Timothy Nikkel (:tnikkel) from comment #11)

(In reply to Peter da Silva from comment #8)

:tnikkel it's not just Facebook. It's also other websites that use the same kind of user interface.

I've only ever seen the problem on facebook so I investigated that. If you want to link to specific non-facebook pages where you see this I can try to reproduce there. Alternatively if you could run https://mozilla.github.io/mozregression/ on those sites to narrow down when this started happened it would be very helpful for moving this investigation forward.

https://twitter.com/

I can't recall any other "infinite scroll" sites I use regularly other than Facebook and Twitter, but I have seen it in long threads in Reddit, where the page is not pseudo-infinite but can get very long.

https://reddit.com/

I originally thought it was a problem with my mouse, but I replaced it and even bought a different make.

Flags: needinfo?(resuna)

Today's update seems to have improved things, but I was able to reproduce it in twitter:

  • Open the twitter feed and set it to most recent tweets.
  • Scroll down Latest Tweets until you're tired of it, keep doing it, a bit more, does the scrollbar look like it's got the same aspect ratio as your car? OK...
  • Switch to notifications.
  • Read a notification, doesn't have to be a new one, just to pull up the stream.
  • Click Home to go back to latest tweets.
  • Scroll down, watch it jerk up and down kinds randomly.
  • Scroll up a page until you've replaced whatever's on the screen.
  • Scroll down again, it's fine.

Not perfect, but there's a usable workaround. Three cheers and a tiger!

Continuing to investigate the fb issue. If I disable scroll anchoring then I see about 3 scroll jumps, during this time the scroll position numerically does not change so it seems the content is changing inside of it. This suggests that we need scroll anchoring in order to avoid a scroll jump here, and the scroll anchoring adjustment that we do see is needed and prevents some scroll jumping but it's not enough to prevent all of the scroll jumping.

(In reply to Timothy Nikkel (:tnikkel) from comment #20)

I think facebook might have changed something on their end, I'm no longer able to reproduce the continual jumping seen in the video in comment 16. However, I am still able to reproduce a scroll jump of about a page height that happens while scrolling down intermittently.

And just to confirm that I can reproduce this less frequent jump in an older build (2022-01-01) so it does not seem to be a recent regression in Firefox.

This seems like per comment 26 that this is not an scroll anchoring issue after all? (sorry for not being able to dig before, Tim)

It seems this might be a regression on Facebook's side then? Ben, are you aware of this issue on the FB side?

Flags: needinfo?(emilio) → needinfo?(b56girard)

(I haven't seen this at all with Twitter/Reddit and I use those fairly frequently)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

This seems like per comment 26 that this is not an scroll anchoring issue after all?

Well, I don't know, fb does seem to be depending on our scroll anchoring to prevent jumping, I'm not sure if our scroll anchoring should be doing better or FB shouldn't be depending that some specific aspect of scroll anchoring that isn't guaranteed?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #29)

(I haven't seen this at all with Twitter/Reddit and I use those fairly frequently)

Same. The STR for twitter seem quite different so let's focus on the biggest problem here with FB, the other sites can be looked at in other bugs.

See Also: → 1784236

I can still reproduce this facebook "infinite scroll" in Nightly105a1(20220811190443).

Yes, I still see this on fb, but it's not as bad as it was two weeks ago. Still something here to fix/investigate (could be on our side or fb side, not sure).

Redirect a needinfo that is pending on an inactive user to the triage owner.
:botond, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(b56girard) → needinfo?(botond)

Sigh. Bad bot. We were hoping that that needinfo would make that inactive user active. Moving it to the component owner is counterproductive for that.

Flags: needinfo?(botond)

I think it might be a site issue because I can reproduce this issue on Nightly from 2020-01-01.

Yes, it is known that is can be reproduced in much older builds.

Then the flag for regressionwindow-wanted should be taken out. Because if it's a site issue then the regression can't be found.

Keywords: regressionwindow-wanted

If it's a site issue it's one that exists on multiple sites and doesn't trigger other browsers.

I've seen it occasionally on sites with "merely" very long pages (ie, Reddit, where all comments on a post are displayed on the same page).

My wild guess is that React does something that are supposed to work on all browsers, but it doesn't work on Firefox. (I am assuming both Facebook and Reddit use React, but I am totally unsure).

We're using this bug specifically to track only the fb issue. I use the other sites that you mentioned that you also see this bug on, but I've only ever seen the problem on fb. So we'll use this bug to track the one reproducible issue. From your description of how you reproduce on twitter it seems to be much more involved, so seems unlikely to be the same problem. It's best to keep bugs focused on one specific issue.

Um, I'm the original reporter. I reported a bug that effects multiple sites. It still effects multiple sites. That is the issue that this bug was opened for.

(In reply to Peter da Silva from comment #41)

Um, I'm the original reporter. I reported a bug that effects multiple sites. It still effects multiple sites. That is the issue that this bug was opened for.

Sometimes, issues on different sites (or even on the same site with different reproduction steps) can have similar symptoms but different underlying causes. For this reason, it's better to track them in separate tickets; if they do turn out to have the same cause, we can always close the other bugs as a duplicate.

With that in mind, could you file a separate bug with the Twitter steps from comment 25 please?

Well, I suppose I can open half a dozen new bugs that you'll close as duplicate, or you can track the facebook bug on one of the other couple of dozen facebook scrolling bugs that are already explicitly about facebook?

I just gave Botond the following context for how FB's feed virtualizer works that might be relevant in understanding this bug:

  • Facebook setups an intersection observer that has 4,000 margin outside the visibile viewport.
  • When an element is rendered in that range, it is measured and it's height is stored
  • When the element is moved 4,000 outside of the viewport, intersection observer notifies the component it's no longer visible.
  • When not visible, it is set to display: none, height: MeausuredHeight. Some React stuff also minimize state updates to it.
  • If the element is unhidden, it will re-render. In some situations the height might have changed. It is most likely unhidden outside the viewport. So the height change should be compensated by scroll anchoring. If it is not done correctly, then the scroll position will jump in an unexpected way.

Emilio said he would take another look at this.

Flags: needinfo?(emilio)
See Also: → 1778186

I did say that, but unfortunately I haven't been able to reproduce the issue here on Nightly nor release (with either my usual extensions or not, X11 or Wayland). I'm just scrolling around in https://www.facebook.com/groups/feed/ and so on, is this somehow macOS specific or am I doing something wrong?

Flags: needinfo?(emilio) → needinfo?(tnikkel)

One thing I do see more obviously on macOS is that the scrollbar jumps, but that seems expected given how these infinite scrolling interfaces are implemented. What's not expected would be if the content would jump...

I found a video uploaded by a user on connect.mozilla.org. It indeed shows us something is broken. It looks to me that the script in Facebook inserts new feeds at a wrong position.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #46)

I did say that, but unfortunately I haven't been able to reproduce the issue here on Nightly nor release (with either my usual extensions or not, X11 or Wayland). I'm just scrolling around in https://www.facebook.com/groups/feed/ and so on, is this somehow macOS specific or am I doing something wrong?

I've only tried scrolling facebook.com directly, not the groups feed. I'll try that and report back.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #48)

I found a video uploaded by a user on connect.mozilla.org. It indeed shows us something is broken. It looks to me that the script in Facebook inserts new feeds at a wrong position.

That video seems to be from the time when the problem was much worse (that seems to have been caused by a change on fb's side that was fixed or backed out). Now it's just one scroll jump, it doesn't repeat.

Okay, so Tim made some changes in our test account and now I can reproduce on the main facebook.com feed (still couldn't repro in the groups feed, so that's probably why). Will try to poke.

Flags: needinfo?(emilio)

Updating bug title to clarify that we're using this bug to track the issue affecting the Facebook feed in particular.

Summary: Scrolling jumps back and forth on sites with "infinite scroll" interfaces. → Scrolling jumps back and forth in the Facebook feed
Severity: -- → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

(In reply to Peter da Silva from comment #43)

or you can track the facebook bug on one of the other couple of dozen facebook scrolling bugs that are already explicitly about facebook?

I chose this bug because it already contains the results of relevant investigation specific to Facebook (for example, comment 15, comment 16, comment 22, comment 44), and it's helpful to keep that in one place.

Okay, so I can confirm a couple things:

  • This doesn't seem to be a scroll anchoring bug per se (I can reproduce it with layout.css.scroll-anchoring.enabled=false).
  • The one difference that comes to mind here is differences in how often and if we dispatch the scroll event. Chrome changed their scroll event dispatch code a while ago: https://chromium-review.googlesource.com/c/chromium/src/+/1928243

The clamping code-path might be relevant here. But I'm still digging a bit more.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #56)

This doesn't seem to be a scroll anchoring bug per se (I can reproduce it with layout.css.scroll-anchoring.enabled=false).

Interesting -- if I recall correctly, Benoit said that Facebook gates their "feed virtualizer" on a check for the overflowAnchor property from script (something like element.style.overflowAnchor I assume). With layout.css.scroll-anchoring.enabled=false, that evaluates to undefined, so Facebook should be disabling their feed virtualizer in that configuration. I guess that suggests the issue is not related to the feed virtualizer after all?

See Also: 1784236 →
Blocks: 1778186

I came across bug 1777619, which seems to have similar symptoms and a reduced testcase.

Is it possible that it's the same underlying issue? (If so, that would be great news because it means we have a reduced testcase to investigate this issue.)

URL: 1777619
URL: 1777619
See Also: → 1777619

I just updated to Firefox 104.0.1 and loaded Facebook, then scrolled all the way down. At first it was stable. But, after a couple minutes the jumping up and down resumed. The previous comments are right about Firefox losing its anchor point. Do I disable the infinite scrolling in about:config?

Follow-up to my last comment.

After adding the value "infinite scrolling" and setting it to false, my auto-scrolling/post jumping issues have stopped. This is with Firefox 104.0.1 64bit on Windows 10. Now, I will begin adding the add-on extensions I was using before and see if the browser stays stable as I scroll down on FB.

In v 104 an improvement, but the problem is still not there. The screen flickers, the feed does not scroll as far as it used to. Sometimes it focuses on the same topic again, sometimes the feed jumps down only one position, but usually much further.

The option "infinite scrolling" [false] does not lead to a positive result, maybe to a further improvement.

The further down the feed is scrolled, the worse it gets.

Goreng is right. Although the jumping and auto-scrolling stopped when I created the infinite scrolling = false key, it just resumed after the browser was open for a half hour. Scrolling all the way down is causing the previous posts to come unanchored.

@Wizcraft, could you clarify please where you changed the "infinite scrolling" setting referenced in comments 63-65?

Flags: needinfo?(software)

@botond
I typed about:config in the address bar and dismissed the earning to get to the configuration screen. I typed in - infinite scrolling - and pressed Enter. The text - infinite scrolling - appeared on the left with three options and a + sign on the right side. Boolean is the default checked option. I then clicked on the large + sign on the right side until the value true appeared, then closed the config tab.

Don't type the dashes or any quotation marks around the phrase in about:config. Exiting after selecting the preferred value saves it.

Flags: needinfo?(software)

Thanks for clarifying. I would expect this to have no effect, as this is not the name of any supported preference. (Our preference names generally don't have spaces in them, and most of them appear in the auto-complete dropdown in about:config.) I'm curious where you got the idea from.

I suspect the reason changes such as version upgrades or configuration changes (especially if accompanied by a browser restart or a page reload) appear to fix the problem temporarily, is that the problem manifests only when the length of the feed is sufficiently long, which requires you to have scrolled a while since loading the page.

I didn't know that our preferences don't have spaces. I read about this property elsewhere in another thread, or another forum, and figured what do I have to lose.

Depends on: 1789930

One of the other sources of this bug I found is this IsProcessingScrollEvent() check in ApplyAdjustments. I haven't dug into detail what Facebook is doing in scroll event handlers, I am not good at tracking down JS thingie.

The script in the scroll event handler in question is;

function() {
  var b = a.pageXOffset,
    c = a.pageYOffset;
  x.current = {
    x: b,
    y: c
  };
  e != null && (y[e] = {
    x: b,
    y: c
  })
}

And the ApplyAdjustments is triggered by the pageXOffset via this GetScrollXY(true).

Okay now I think I understand what Emilio told in comment 56. Chrome fixed infinite scroll event loop triggered by scroll anchoring in a different way so that they are able to apply scroll anchoring in scroll event handlers.

Flags: needinfo?(tnikkel)
See Also: 1777619 →

Emilio realized me in a review comment, scroll anchoring isn't a silver bullet to adjust scroll position. Indeed it doesn't guarantee the scroll position whenever layout is changed. So for example, a sentence from the spec

At the end of a suppression window, the user agent performs all scroll adjustments that were queued during the window and not suppressed by any suppression trigger during the window.

It doesn't say "the user agent MUST perform" or SHOULD or some such.

That being said, I think querying pageYOffset or scrollY or some such in scroll event handlers is a very common pattern used in the wild. That's quite unfortunate we can't apply scroll anchoring in such cases. So I'd like to propose a new heuristic way to avoid infinite scroll event loop like infinite-scroll-event.tentative.html.

The way is similar to what Chrome does (as Emilio referred in comment 56), but slightly different. The way I have in my mind is;

  1. Record the current scroll position just before we are trying to apply scroll anchoring if we are in scroll event handlers
  2. Then at the very next time we are trying to apply scroll anchoring if the recorded scroll position equals to the new position where we are trying to adjust, then we disable later scroll anchoring

This way will break infinite-scroll-event.tentative.html actually, but I think it's better than what Chrome does, not firing scroll event even if the scroll position was changed is weird to me.

Honestly I am not sure this will perfectly work in any cases of the infinite scroll event loops, but even if there are some cases don't work, we could improve the heuristic? It may mis-consider the situation, but it would be okay, since it doesn't mean worse than the current situation because the new heuristic is also involving scroll event handlers. It may miss the infinite scroll event loop, that would be a big problem.

That may not be a great idea. Infinite scroll event loop can be caused easily, something like;

let height = 100;
window.addEventListener("scroll", () => {
  element.style.height = height + "px";
  element.offsetTop;
  height += 100;
});

We could rather detect whether there's any style changes in scroll event handlers? Then we could apply scroll anchoring in the case of comment 73?

I'm not into the actual engine and its javascript and css properties. But, I am into experimenting with under the hood settings.

So, I thought about what is probably happening when I load Facebook and keep scrolling down to load more content. As the posts load, they go into the Firefox cache. That cache has a default set limit of about 15mb. After that is reached the data must be swapped out to the main RAM. I figured I have nothing to lose by doubling the size of the browser cache, so I did that.

browser.cache.disk.capacity = 307200

Since doubling the browser cache setting the jumping of scrolled posts is greatly reduced. I have had this setting for about 48 hours now and the results seem repeatable. I will increase the browser cache again tonight and see if if makes any noticeable difference over the next day, then report back here.

Followup to my last comment (77).
I increased the value of the browser.cache.disk.capacity to 460800 and while it takes slightly longer for Facebook to fully load, the post jumping on scrolling problem has virtually disappeared. I also enabled smooth scrolling on a hunch. I hope this helps point you gurus in the right direction to resolve the problem.

I just found a similar bug report on chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=1346847), which was reported on this July 23rd.

See Also: → https://bugs.chromium.org/p/chromium/issues/detail?id=1346847

(In reply to Wizcrafts from comment #79)

Followup to my last comment (77).
I increased the value of the browser.cache.disk.capacity to 460800 and while it takes slightly longer for Facebook to fully load, the post jumping on scrolling problem has virtually disappeared. I also enabled smooth scrolling on a hunch. I hope this helps point you gurus in the right direction to resolve the problem.

Out of curiosity I tried this as well, I set it to: 512000

  • The infinite scroll being fixed at the bottom (thus triggering the infinite scroll loading) - stopped.
  • As a bonus, FF stopped crashing / slowing down because of Facebook (my workaround is to close the tab, if I still can, then open a new tab)
  • Did not experience the "while it takes slightly longer for Facebook", on my end it seems faster than usual.

Meta:

  • Firefox: v106.0b3 (64-bit)
  • OS: Pop! OS 22.04 LTS
  • Tested on: Facebook
  • Tested: Maximized window
  • Tested: Tiled window

I hope it helps in whatever way.

My browser.cache.disk.capacity has been at 512000 the whole time I have been experiencing this issue.

Does it matter whether scrolling is in the default order, or after selecting "Most Recent" order? Is the placeholder behavior different when loading from the different options? Today, after near-perfect smooth scrolling in v 105.0.1, OS Monterey 12.6, since 9/28, Most Recent first, jumping posts and autoload with continuous scrolling returned. Quit Ffx and relaunch, scrolling in default order, smooth scrolling was uninterrupted.

Don't know if this helps or not, but I think I have experienced this same bug for a while on Facebook.com's home page, while logged in. It may be present on other sites, but I have not been on sites such as Twitter.com lately, only Facebook.

I'm on Mac OS and just installed a fresh instance of Nightly 107.0a1 (2022-10-01) (64-bit).

What happens:
When I go to Facebook's home page, once logged in, I scroll the content up into view and when I get to about 35 posts, the page jumps 2 or 3 posts ahead, and if one scrolls more, sometimes the page will flash new multiple posts or parts of the page every 1/4 of a second or so. I do not think this has ever occurred just at the top of the feed, only once I have scrolled a number of posts up into the view area.

What should happen:
Should scroll smoothly and show all of the posts on the feed smoothly.

I am hoping this is the same bug as this bug report I am contributing to now, if not, please let me know and I will open up a new bug report. Thanks. I hope this is helpful.

(In reply to Dean Edridge [:deanedridge] from comment #84)

Don't know if this helps or not, but I think I have experienced this same bug for a while on Facebook.com's home page, while logged in. It may be present on other sites, but I have not been on sites such as Twitter.com lately, only Facebook.

I'm on Mac OS and just installed a fresh instance of Nightly 107.0a1 (2022-10-01) (64-bit).

What happens:
When I go to Facebook's home page, once logged in, I scroll the content up into view and when I get to about 35 posts, the page jumps 2 or 3 posts ahead, and if one scrolls more, sometimes the page will flash new multiple posts or parts of the page every 1/4 of a second or so. I do not think this has ever occurred just at the top of the feed, only once I have scrolled a number of posts up into the view area.

What should happen:
Should scroll smoothly and show all of the posts on the feed smoothly.

I am hoping this is the same bug as this bug report I am contributing to now, if not, please let me know and I will open up a new bug report. Thanks. I hope this is helpful.

I should add: Changing the page's zoom, does not appear to make a difference. I often have Facebook zoomed in at 120% but this does not appear to affect the bug.

Now this problem is fixed, I think it was a problem of Facebook itself,

Of course, immediately checked, after previously deleting the cookies.

Unfortunately, the NewsFeed still jumps unchanged. Clicking through images is also spinning now, but not always.

Firefox 105.0.2 (64bit), 2022_10_06, 03:08pm

I also still have the problem.

There's an open issue for the scroll anchoring spec (I was redirected to the issue from an issue that Emilio proposed to solve this Facebook isssue), that is adding an opt-in way to stop doing any heuristics for not applying scroll anchoring. Once after the spec issue is resolved and we implemented it, then we can use it in our web interventions extension for this Facebook issue.

A good news I can share is that in the next release version, 106, it's including bug 1789930, thus in cases of keyboard or mouse wheel scrolling, this jumpy scrolling will be less often happening before.

I've seen this for Long Time (many months IIRC) on Windows Nightly ASAN builds. Similar to above, as I scroll further and further it starts jumping 2 or 3 articles (sometimes with a bit of back-and-forth before stabilizing); it seems to jump further as I continue to scroll down. Definitely seems related to loading new content (I can often see images paint in as they're loaded as it jumps around).

Too bad, that means the matter is still not solved. Not even with version 106.

In addition, there is a problem when browsing images from posts with multiple images from the newsfeed. If our problem occurs, scrolling through is no longer possible.

When scrolling, you get to one of the upstream postings.

When you click on the "X" to close, nothing happens.

One has to use the back button of the browser to get back to the newsfeed and close the image view.

This behavior occurs when the scrolling problem has occurred, until then everything works.

Translated with www.DeepL.com/Translator (free version)

I've reached out to Facebook to ask if they can assist investigating this. I'll leave a comment if I get a substantial response.

Keywords: webcompat:site-wait

FWIW, I manage a FB group that provides tech support for a FB-related extension and there have been complaints of this behavior with non-FF browsers.

(In reply to Ed from comment #93)

FWIW, I manage a FB group that provides tech support for a FB-related extension and there have been complaints of this behavior with non-FF browsers.

Aha!

(In reply to GORENG from comment #91)

Too bad, that means the matter is still not solved. Not even with version 106.

In addition, there is a problem when browsing images from posts with multiple images from the newsfeed. If our problem occurs, scrolling through is no longer possible.

When scrolling, you get to one of the upstream postings.

When you click on the "X" to close, nothing happens.

One has to use the back button of the browser to get back to the newsfeed and close the image view.

This behavior occurs when the scrolling problem has occurred, until then everything works.

Translated with www.DeepL.com/Translator (free version)

I have also experienced this problem with strange behavior in Facebook which starts when trying to view individual images from posts. This problem also does not happen all of the time, but if I have been browsing and scrolling for a length of time I run into the problem. This issue is newer than the scrolling issue, but I believe it is related. Either I have already been dealing with the scrolling issue whenever I have had this new problem or (if I am able to return to the main news feed page after trying to view the images) the scrolling issue happens right afterwards. Sometimes opening Facebook in a new tab helps, but sometimes I need to close Firefox completely and then reopen it - which clears out the history/cache. It seems to be related to some kind of buffer or the cache getting filled up. However, there is no issue with other sites, so the total cache on Firefox is evidently not overly full. (I am just a user and not a tech person, but I hope this info helps.) I am currently using Firefox 105.0.3 on Windows 10 Pro.

I have the issue also. Desktop, wins 10. Firefox.

When I reported this bug three months ago (https://bugzilla.mozilla.org/show_bug.cgi?id=1783046) I thought it would be fixed in a short time. I had no idea That it would bring so many developers and common users like me into the discussion. About a month ago we were told that a fix was being developed and would be rolled out in Firefox 106. Well, version 106 is here and I still have automatic scrolling after either pressing page down multiple times, or using my mouse wheel to scroll down until it bottoms out. I tried closing the browser, emptying the cache and reopening it to Facebook. Same problem as before. Things scroll smoothly for a minute or so, then BAM, posts jump on their own. There are two ways to stop it. Once is clicking the refresh button. The other is closing the browser and reopening it.

In case anybody thinks I'm a newbie to Firefox, know that I was using Netscape Navigator in the late 1990s. I was still using it when AOL let it go and Mozilla formed and took over and rebranded it as Firefox. I have faith that eventually the self scrolling code problem with Facebook (and possibly other sites) will be resolved and we'll have a stable experience on that website, using Firefox rather than Chrome, Edge, or the Facebook App.

NB: There is currently no such auto-scrolling, or post jumping around problem for me with Google Chrome on my Windows 10 Pro PC, which has 32Gb of DDR4 Crucial Ballistics RAM and a 500Gb Samsung SSD. The problem is entirely in Fx, all the way up to and including v106.0.

(In reply to Wizcrafts from comment #98)

The problem is entirely in Fx

Not true - see my comment #93 above. However, it does occur a lot more in FF.

It's not fixed, and it's gotten worse in some ways. Even relatively short pages on virtualverse.one are getting scrolling problems... and I know VV1 hasn't updated their code in yonks.

I tried to reproduce scroll jumps on fb main page feed when using the page down key repeatedly, using the mouse wheel to scroll to the end of loaded content, and using mouse auto scroll to scroll to the bottom. I was not able to reproduce any scroll jumps.

(In reply to Timothy Nikkel (:tnikkel) from comment #101)

I tried to reproduce scroll jumps on fb main page feed when using the page down key repeatedly, using the mouse wheel to scroll to the end of loaded content, and using mouse auto scroll to scroll to the bottom. I was not able to reproduce any scroll jumps.

It started jumping on me just now. I scrolled Facebook a lot longer than usual before the jumps started, but the problem is still there.

(In reply to ajpeavler from comment #102)

(In reply to Timothy Nikkel (:tnikkel) from comment #101)

I tried to reproduce scroll jumps on fb main page feed when using the page down key repeatedly, using the mouse wheel to scroll to the end of loaded content, and using mouse auto scroll to scroll to the bottom. I was not able to reproduce any scroll jumps.

It started jumping on me just now. I scrolled Facebook a lot longer than usual before the jumps started, but the problem is still there.

First, can you confirm that you are on version 106?

Then, can you describe in detail which page on fb you were scrolling and the method of scrolling and how you were scrolling and how much scroll jumping? ie "I was scrolling down while scanning each item quickly using the touchpad and there was one scroll jump" or "I scrolled all the way to the bottom using the mousewheel and the page just kept scrolling without me". I will try to reproduce myself using these instructions, so please try to include enough detail for another person to be able to follow.

(In reply to Timothy Nikkel (:tnikkel) from comment #103)

(In reply to ajpeavler from comment #102)

(In reply to Timothy Nikkel (:tnikkel) from comment #101)

I tried to reproduce scroll jumps on fb main page feed when using the page down key repeatedly, using the mouse wheel to scroll to the end of loaded content, and using mouse auto scroll to scroll to the bottom. I was not able to reproduce any scroll jumps.

It started jumping on me just now. I scrolled Facebook a lot longer than usual before the jumps started, but the problem is still there.

First, can you confirm that you are on version 106?

Then, can you describe in detail which page on fb you were scrolling and the method of scrolling and how you were scrolling and how much scroll jumping? ie "I was scrolling down while scanning each item quickly using the touchpad and there was one scroll jump" or "I scrolled all the way to the bottom using the mousewheel and the page just kept scrolling without me". I will try to reproduce myself using these instructions, so please try to include enough detail for another person to be able to follow.

Yes, I am on FF version 106.0. I was on the main news feed page and was using the mouse wheel to scroll while reading through the posts. My touchpad is disabled; I use a small wireless mouse. I wasn't scrolling particularly fast; I was reading the posts. The feed was in the default order; I had not changed it to "most recent." It worked great for a long time; then suddenly it jumped down and skipped a few posts. I scrolled back up without much trouble and continued reading. Soon afterwards, it jumped again, maybe a little more that time, I'm not sure. It did keep getting worse and after another jump or two I had more trouble scrolling back up. I think more posts were skipped, but I think it also kept jumping as I was trying to scroll back up because I passed the same posts more than once until I got back up and found my place. The last time it jumped, I read the bottom post and scrolled slowly and just read the posts from the bottom up until I got back to where I left off. Then I gave up and went to my email and found the notification about this bug thread. I have a 3 1/2 year old Toshiba laptop running Windows 10 Pro. The processor is "Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz 2.70 GHz" and is not compatible with Windows 11. I have 16 GB RAM and a 1 TB hard drive which is less than half full.

Been doing this for me forever. Still doing it on latest FF build. Glad to know it's not just me.

I've not had a scrolling problem for several days. It seems to be fixed now; maybe Facebook finally fixed it. Several users on the Mozilla Connects forum have reported that the problem seems to be fixed. https://connect.mozilla.org/t5/discussions/firefox-scrolling-jumps-in-facebook/m-p/9054/thread-id/3788

Definitely not fixed.

Just tried FB on Firefox, bounces around like a basketball. Can't see using FF fulltime til this gets fixed.

This issue is still happening with Firefox 107.0.1 (Linux).

(In reply to pasik from comment #109)

This issue is still happening with Firefox 107.0.1 (Linux).

YES!

Also happening in Mastodon (ohai.social).

It was fixed for awhile (see my last comment above), but it started again a couple of weeks ago. Facebook had updated it's layout a few days before I noticed the scrolling problem again. Coincidentally or not, the problem re-started for me when my Firefox updated to version 108.0.1. Some users on the Mozilla Connects forum have said it started prior to their browser updating to the latest version.

Curious if when you repro there's a warning on the console like:

Scroll anchoring was disabled in a scroll container because of too many consecutive adjustments (...)

Flags: needinfo?(emilio)

hmm, I don't see any "scroll anchoring was disabled" errors in the developer console, but I do see lots of failed/red requests with the reason NS_BINDING_ABORTED when those jumps happen..

i found scroll anchoring may not works in some case. and i open new bug for that (Bug1808077)

i not sure is it root cause or not. but i want to let you known.

for me when this issue happen in developer console it show
Scroll anchoring was disabled in a scroll container because of too many consecutive adjustment (10) with too little total distance (-2.73166675567627 px average, -27.3167 px total)

as you can see in https://youtu.be/qZV9Nq8_SX4

Flags: needinfo?(emilio)

Thanks, does setting layout.css.scroll-anchoring.max-consecutive-adjustments=0 in about:config fix this for you?

Flags: needinfo?(emilio) → needinfo?(mix5003)

after i try that config. i think problem still exists. but more better.
before set when i found this problem it will jump and jump many times (may be infinite i do anything in that page).
but after i set this when i found this problem it jump only once and in short distance.

but i can not sure is it same problem or not. for me this issue is random and not easy to reproduce.

Flags: needinfo?(mix5003)

this video show what i mean better https://youtu.be/2oqHGxu-3LE (jump only once at second 2-3)
compare to original version https://youtu.be/qZV9Nq8_SX4 (jump to end every 2-3 sec, may be after loaded new feed data)

and base from my memory i think issue trigger rate is lower.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:botond, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dg) → needinfo?(botond)
Flags: needinfo?(botond)

I apologize for my recent silence in this topic. The reason is that the issue appeared to be resolved in November and early December. Unfortunately, something has been done to Firefox that has caused the auto scrolling and jumping to return for me. It happens after I have loaded many posts and scrolled down a few times. I leave Firefox open for hours at a time and have many tabs open. This could impact the jumping problem compared to someone with fewer open tabs.

I have tried a couple of about:config changes that have been posted, but none have resolved the issue for very long.

Lastly, the problem is not occurring in Chrome or Edge at this point in time. I sometimes keep Chrome open on Facebook when I have posts to read and respond to and Firefox gets jumpy. This is not the ideal solution. Comeon Navigator's child, get it together!

I am changing changing the spec issue I posted here before from issue 4264 to issue 7745. The background story is that the issue 7745 was closed as a duplicate of the issue 4264 once, then the CSSWG discussed in a meeting and concluded they are different.

For people who has been suffering from this issue; Firefox hasn't changed code around scroll-anchoring which is the area related to this issue. So I am pretty sure Facebook changed something and it solved this issue (unexpectedly for them), then they changed again.

See Also: https://github.com/w3c/csswg-drafts/issues/4264 → https://github.com/w3c/csswg-drafts/issues/7745

The problem was consistently present in Firefox. It varies from time to time, but it has never been gone.

Before it occurred, it was easily possible to scroll through hundreds of posts. Currently, after "jumping", 10 or 20 of the scrolled posts are still visible, although there should be many more.

So it's not just jumping down that's happening, there's a "reload" happening at the top, limited to the last few posts viewed.

See Also: → 1808077

From here: https://www.camp-firefox.de/forum/thema/134975-facebook-seiten-springen-unkontrolliert-beim-scrollen/?pageNo=5

»Short update on this from me:

For me, it seems to have been a problem with the tab environments.

At first, I had only ever activated the Facebook container.

When there was a Firefox multi-container, I used it and deactivated the Facebook container.

But now I had to move to a new laptop and in the process (for whatever reason) both container add-ons were active. After deactivating the Facebook container again, nothing "jumps" for me anymore ... and this has been going on for almost 2 weeks now.

Maybe it will help others too :)«

This is exactly how it works! However, clicking through pictures in posts with several pictures is still disturbed. The "X" to close the picture view has no function and the only way to return to the TimeLine is to use the back button in Firefox. This only occurs after a long scroll through the TimeLine.

(In reply to GORENG from comment #126)

From here: https://www.camp-firefox.de/forum/thema/134975-facebook-seiten-springen-unkontrolliert-beim-scrollen/?pageNo=5

»Short update on this from me:

For me, it seems to have been a problem with the tab environments.

At first, I had only ever activated the Facebook container.

When there was a Firefox multi-container, I used it and deactivated the Facebook container.

But now I had to move to a new laptop and in the process (for whatever reason) both container add-ons were active. After deactivating the Facebook container again, nothing "jumps" for me anymore ... and this has been going on for almost 2 weeks now.

Maybe it will help others too :)«

This is exactly how it works! However, clicking through pictures in posts with several pictures is still disturbed. The "X" to close the picture view has no function and the only way to return to the TimeLine is to use the back button in Firefox. This only occurs after a long scroll through the TimeLine.

This seems to help indeed.
I have disabled the FB container (i don't use other containers) and everything is fine for now.
I will keep an eye, though.

Thanks!

(In reply to vyrgozunqk from comment #127)

(In reply to GORENG from comment #126)

From here: https://www.camp-firefox.de/forum/thema/134975-facebook-seiten-springen-unkontrolliert-beim-scrollen/?pageNo=5

»Short update on this from me:

For me, it seems to have been a problem with the tab environments.

At first, I had only ever activated the Facebook container.

When there was a Firefox multi-container, I used it and deactivated the Facebook container.

But now I had to move to a new laptop and in the process (for whatever reason) both container add-ons were active. After deactivating the Facebook container again, nothing "jumps" for me anymore ... and this has been going on for almost 2 weeks now.

Maybe it will help others too :)«

This is exactly how it works! However, clicking through pictures in posts with several pictures is still disturbed. The "X" to close the picture view has no function and the only way to return to the TimeLine is to use the back button in Firefox. This only occurs after a long scroll through the TimeLine.

This seems to help indeed.
I have disabled the FB container (i don't use other containers) and everything is fine for now.
I will keep an eye, though.

Thanks!

Would you please check the described behaviour regarding the images?

It only occurs when many posts have been scrolled through. Just stress the mouse wheel for 1 minute and then click on a post with more than 1 picture. Can you then close the picture view with the "X" at the top left?

FF v 109, Mac Ventura. Facebook container enabled.
Scroll many posts in most-recent first order. Click to view photo array. Arrow-right to view all photos. Click X to close photos. The feed reloads at some wrong place, and lines of small type appear at the left of the screen. Need to use browser back button to find earlier place in the feed.
Hope this helps.

I've had the problems with closing the images, too. I'm on Windows Pro and do not use Facebook Container or any of the other extensions. I also keep my news feed in the default order. The scrolling issues seemed to be fixed again as of last night, but I have been noticing the problem with not being able to close the images, again. At least this time clicking the X does not take me to a random page on Facebook - which it did sometimes in the past; now it just doesn't do anything. I am able to go back to my news feed by hitting the "ESC" button on my laptop keyboard.

(In reply to GORENG from comment #128)

(In reply to vyrgozunqk from comment #127)

(In reply to GORENG from comment #126)

From here: https://www.camp-firefox.de/forum/thema/134975-facebook-seiten-springen-unkontrolliert-beim-scrollen/?pageNo=5

»Short update on this from me:

For me, it seems to have been a problem with the tab environments.

At first, I had only ever activated the Facebook container.

When there was a Firefox multi-container, I used it and deactivated the Facebook container.

But now I had to move to a new laptop and in the process (for whatever reason) both container add-ons were active. After deactivating the Facebook container again, nothing "jumps" for me anymore ... and this has been going on for almost 2 weeks now.

Maybe it will help others too :)«

This is exactly how it works! However, clicking through pictures in posts with several pictures is still disturbed. The "X" to close the picture view has no function and the only way to return to the TimeLine is to use the back button in Firefox. This only occurs after a long scroll through the TimeLine.

This seems to help indeed.
I have disabled the FB container (i don't use other containers) and everything is fine for now.
I will keep an eye, though.

Thanks!

Would you please check the described behaviour regarding the images?

It only occurs when many posts have been scrolled through. Just stress the mouse wheel for 1 minute and then click on a post with more than 1 picture. Can you then close the picture view with the "X" at the top left?

After I have disabled the containers, I have no issues with scrolling or closing images, on Mac though.
I've scrolled a lot, up and down, i have Logitech mouse with free-spinning wheel and just rotated it like mad... No issues at all.
Then i've found a post with few images, opened some of them randomly, everything was fine with the close button.

(In reply to harvey.kabaker from comment #129)

FF v 109, Mac Ventura. Facebook container enabled.
Scroll many posts in most-recent first order. Click to view photo array. Arrow-right to view all photos. Click X to close photos. The feed reloads at some wrong place, and lines of small type appear at the left of the screen. Need to use browser back button to find earlier place in the feed.
Hope this helps.

I disabled the FB container and have no others running.

No problems scrolling through many posts smoothly. Stopped to browse multiple photos in one post. This time the X cannot close the photo window, and several lines in small type appear at the left, superimposed over the picture. Going back to enable FB container.

For me the problem ceased to exist yesterday. I did not update Firefox. Using a Linux OS and no containers.

Welp, today the jumping is back, but on the brighter side, there's no problem viewing multi-photo posts, closing with the X, and returning to the right place. Still v 109.0, Mac Ventura.

(In reply to watchman from comment #133)

For me the problem ceased to exist yesterday. I did not update Firefox. Using a Linux OS and no containers.

I commented too soon. Scrolling worked well only for 2 days. Since then it has reverted. It is impracticable to scroll to the earliest point in the feed and then scroll upwards, which is the logical way to read the feed, because most posts above your position disappear. (The feed is in descending chronological order.) Skipping posts when downward scrolling is erratic, some times worse than others.

I am currently running Firefox version 110.0.1 64 bit on Windows 10 Pro, 64 bit. It is March 6, 2023. My PC uses a Logitech USB wheel mouse. My CPU is an AMD Ryzen 5 2400G. I'm running 32 Gb of Crucial Ballistics DDR 4 Ram. I am not overclocking at all. Both CPU and RAM are running at their default speed. The CPU and case temperatures are within nominal operating parameters.

I'm sad to report that the Facebook scroll jumping defect is still happening whenever I scroll down the page. When this happens I lose visibility of the post that was in my view at the moment and have to scroll up if I want to read it. Sometimes there are several continuous jumps until Facebook stabilizes, or I hit Shift and F5 to force a total page reload. Then it happens again as I scroll down. Whatever changes were made aren't working anymore. For a while, this scroll jumping only happened after the browser was busy for a long time. Now, it happens almost from the get go. This problem is not present in Google Chrome or MS Edge.

If anybody has a good workaround, I'd love to see it.

Depends on: 1833758

I'm now on Firefox 113.0.1. The scroll jumping is starting to get more controllable in this release. While it still happens, the distance the posts jump is less than before. I believe a fix is within eyesight (I hope).

Are the developers still working on getting this fixed? It's been a year now! Mine had been working much better for several days, but tonight after yesterday's Firefox update to 117.0 the issue is worse than ever. Someone on the Mozilla Connect forum has been suggesting that we go to about:config and change layout.css.scroll-anchoring.enabled from "true" to "false." I have been concerned that this might cause issues with other sites, but tonight I'm going to try it. Trying to scroll Facebook was ridiculous tonight! I'm using:
Windows 10 Pro
Version 22H2
Installed on ‎6/‎14/‎2020
OS build 19045.3324
Experience Windows Feature Experience Pack 1000.19041.1000.0

See Also: → 1852818
See Also: → 1786658

As I posted 26 days ago, I decided to try the work-around suggested on the forum and went into "about:config" and changed the setting of layout.css.scroll-anchoring.enabled from "true" to "false." I would like to report that this stopped the backwards jumping when I scrolled. It fixed it immediately, and it hasn't come back. I have also not noticed any issues on other sites. However, on Facebook now another issue has returned. After I have scrolled awhile and then click into a picture to enlarge it (and maybe view other pictures in the post) or when I click to view more comments or to type a comment (which now brings up a popup window/frame in the middle of the screen), sometimes trying to close out the popup window/frame will cause the screen to go to some random page on Facebook and will not return me to my news feed. I assume this happens when some kind of buffer is full. However, it is preferable to all of the jumping that was going on while trying to scroll.

Another issue with Facebook which may or may not be related is that now when I "react" to a post the screen often jumps back several posts. Someone else also made an unclear comment about this happening when they use a reaction other than "like." Since reading that comment, I've noticed that the "like" reaction does not seem to cause the screen to jump. Also, if the screen has been jumping with other reactions, once I use "like" on a post, the jumping will stop at least temporarily. I only started noticing this after I change the above setting, but it may only be a coincidence. I have this issue when scrolling through a profile with a lot of posts, as well as when scrolling through the news feed. I did not have the original issue of the posts jumping when trying to scroll down the page when I was on a profile page; that issue only happened in news feed.

Hey ajpeavler, would you mind trying the latest nightly (which should include the fix for bug 1852818)?

Recently we found a scroll-anchoring bug (bug 1852818) that I suspect the bug is one of the reasons of this bug. So I'd hope on the latest nightly this Facebook's jumpy scroll issue has been solved or at least it's been mitigated. Thanks!

Note that we don't recommend to change the default value of layout.css.scroll-anchoring.enabled.

Flags: needinfo?(ajpeavler)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #140)

Hey ajpeavler, would you mind trying the latest nightly (which should include the fix for bug 1852818)?

Recently we found a scroll-anchoring bug (bug 1852818) that I suspect the bug is one of the reasons of this bug. So I'd hope on the latest nightly this Facebook's jumpy scroll issue has been solved or at least it's been mitigated. Thanks!

Note that we don't recommend to change the default value of layout.css.scroll-anchoring.enabled.

Nightly 120.0a1 (2023-09-26) does not fix it for me on Win11 Pro 22h2 22621.2283.

Thanks for the quick response. That's unfortunate though. There's definitely something we are not aware of.

I would encourage everyone who still experiences this bug to also report it to Facebook Support, just to attack the issue from another angle.

We will continue to try to reproduce the remaining issues and make fixes, but due to the intermittent nature of the problem and the complexity of the Facebook website it's a challenging one to track down. Facebook engineers have some advantages over us in investigating this: they have access to the non-obfuscated version of Facebook's Javascript code, and they have a better understanding of how their mechanism for lazy loading/unloading of posts works. Even if the underlying bug is a browser issue, if Facebook engineers are able to prepare a reduced testcase that demonstrates the browser issue, that would make it much easier for us to fix.

The problem is not limited to Facebook. When I originally opened this ticket, it referred to the jumping problem on any website, particularly those with very long or "infinite" pages, but it even happens on sites with relatively short pagination. It got redirected to concentrate on Facebook but if you're looking for simpler examples you can get the same behavior on twitter, reddit, and phpbb.

(In reply to Peter da Silva from comment #144)

The problem is not limited to Facebook. When I originally opened this ticket, it referred to the jumping problem on any website, particularly those with very long or "infinite" pages, but it even happens on sites with relatively short pagination. It got redirected to concentrate on Facebook but if you're looking for simpler examples you can get the same behavior on twitter, reddit, and phpbb.

There may be multiple issues here. The fact that we've had a fairly high volume of users reporting issues on the Facebook feed specifically, and comparatively few users reporting similar issues on Twitter or Reddit, suggests to me that there are at leats some issues specific to the Facebook feed's scrolling mechanism in particular.

You were looking for a simpler repro. I suggest it may be worthwhile to try other platforms to see if they can provide useful information.

(In reply to Ed from comment #141)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #140)

Hey ajpeavler, would you mind trying the latest nightly (which should include the fix for bug 1852818)?

Recently we found a scroll-anchoring bug (bug 1852818) that I suspect the bug is one of the reasons of this bug. So I'd hope on the latest nightly this Facebook's jumpy scroll issue has been solved or at least it's been mitigated. Thanks!

Note that we don't recommend to change the default value of layout.css.scroll-anchoring.enabled.

Nightly 120.0a1 (2023-09-26) does not fix it for me on Win11 Pro 22h2 22621.2283.

I'm not sure what you mean by "nightly" - I'm just a user and not a developer and don't install any beta versions - but my Firefox updated to version 118.0 last night/early this morning, so I have now reset layout.css.scroll-anchoring.enabled back to the default value and will try Facebook again later tonight. It seems as if Facebook has made more subtle changes recently; the "reaction" icons now look different when you hover over them. So who knows what else they have done to their code. In the past the problem seems to have gotten better for a while but then reoccurred.

Flags: needinfo?(ajpeavler)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #140)

Hey ajpeavler, would you mind trying the latest nightly (which should include the fix for bug 1852818)?

Recently we found a scroll-anchoring bug (bug 1852818) that I suspect the bug is one of the reasons of this bug. So I'd hope on the latest nightly this Facebook's jumpy scroll issue has been solved or at least it's been mitigated. Thanks!

Note that we don't recommend to change the default value of layout.css.scroll-anchoring.enabled.

I'm not sure what you mean by "nightly"; I am a user and not a developer so I don't download the test versions. However, my browser did update to version 118.0 last night/this morning. I have now had a chance to reset layout.css.scroll-anchoring.enabled back to the default value of "true" and try Facebook again. It didn't take too long before I got a jump when scrolling. Then when I continued scrolling, it jumped again and the content of the page changed almost completely. It wasn't that far back to the top, and almost all of the posts I'd previously seen were gone. So I'm going back to layout.css.scroll-anchoring.enabled set to "false" because it's better that way. If I run into other issues, I can always change it back later.

Attached file A test case —

Okay, I can reproduce the jumps. A way to reproduce the issue I found is;

  1. Scroll to near the bottom edge where while blank place holders don't appear
  2. Wait several seconds
  3. Repeat 1) and 2), you will see jumps

Attaching file is replicating this issue, it's similar to bug 1852818 but it's simpler than that.

The jumpy scroll position comes from this GetVisualScrollOffset value in FrameMetrics::ApplyRelativeScrollUpdateFrom when we apply scroll anchoring adjustments. In cases the content height got shrunk we clamp the GetVisualScrollOffset value but it's done after doing the ApplyRelativeScrollUpdateFrom (and also we don't clamp if we did ApplyRelativeScrollUpdateFrom).

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED

When we update new relative scroll offsets in an APZC, we use the last scroll
offset. Thus if the last scroll offset is out of bounds, relative scroll offset
updates will result wrong scroll destinations.

Depends on D189687

See Also: → 1856088
Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8bae3301e31d
Rename testing/web-platform/tests/css/css-scroll-anchoring/after-scrollable-range-shrinkage.html. r=botond
https://hg.mozilla.org/integration/autoland/rev/4ff9f4b0a7af
Re-clamp the last scroll offset before updating new scroll offsets. r=botond
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/42302 for changes under testing/web-platform/tests

https://hg.mozilla.org/mozilla-central/rev/8bae3301e31d
https://hg.mozilla.org/mozilla-central/rev/4ff9f4b0a7af

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
status-firefox120: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 120 Branch
Upstream PR merged by moz-wptsync-bot

:hiro do you want to mention this in the fx120 release notes? https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination

Flags: needinfo?(hikezoe.birchill)

This is a pretty big QoL fix, definitely seems worth calling out in some form if you ask me.

status-firefox118: --- → wontfix
status-firefox119: --- → fix-optional
status-firefox-esr115: --- → affected
Flags: in-testsuite+

Comment on attachment 9355941 [details]
Bug 1779404 - Re-clamp the last scroll offset before updating new scroll offsets. r?botond

Beta/Release Uplift Approval Request

  • User impact if declined: Users will see undesired scroll position jumps
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce: On Facebook
  1. Scroll to near the bottom edge where while blank place holders don't appear
  2. Wait several seconds
  3. Repeat 1) and 2), you will see jumps
  • List of other uplifts needed: bug 1852818
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The change itself is quite simple, it will never cause severe issues such as crashes or hangs.
  • String changes made/needed: none
  • Is Android affected?: Yes
Flags: needinfo?(hikezoe.birchill)
Attachment #9355941 - Flags: approval-mozilla-beta?
Attachment #9355940 - Flags: approval-mozilla-beta?

Comment on attachment 9355940 [details]
Bug 1779404 - Rename testing/web-platform/tests/css/css-scroll-anchoring/after-scrollable-range-shrinkage.html. r?botond

Approved for 119.0b5

Attachment #9355940 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9355941 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Backed out for causing refttest and mochitest plain failures on beta
https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=9bb86c200658a7dc1d44f05d5275db9c605599f3

Push with failures: https://treeherder.mozilla.org/jobs?repo=mozilla-beta&selectedTaskRun=MzpjLgI4R8GjolxGzW[…]ae1c545bad65ea0147bb9c3d884c5d0d1ebcfa2&searchStr=reftest

[task 2023-10-04T01:23:44.068Z] 01:23:44 INFO - REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/invalidation/540247-1.xhtml == layout/reftests/invalidation/540247-1-ref.xhtml | image comparison, max difference: 255, number of differing pixels: 14120

Mochitest plain failures: https://treeherder.mozilla.org/jobs?repo=mozilla-beta&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&fromchange=aae1c545bad65ea0147bb9c3d884c5d0d1ebcfa2&searchStr=mochitest%2Cplain&selectedTaskRun=N79T09BTQt6Dr3X_y1EOCg.0&tochange=aae1c545bad65ea0147bb9c3d884c5d0d1ebcfa2

Setting NI as a formality but already discussed via slack.

status-firefox119: fixed → affected
Flags: needinfo?(hikezoe.birchill)

Comment on attachment 9355940 [details]
Bug 1779404 - Rename testing/web-platform/tests/css/css-scroll-anchoring/after-scrollable-range-shrinkage.html. r?botond

Feel free to reopen beta nomination once issue is investigated

Attachment #9355940 - Flags: approval-mozilla-beta+ → approval-mozilla-beta-
Attachment #9355941 - Flags: approval-mozilla-beta+ → approval-mozilla-beta-

Okay the failure is caused by the lack of bug 1852818 on the beta branch. I am surprised that D189687 can be landed without bug 1852818.

Flags: needinfo?(hikezoe.birchill)

Hmm I can no longer change the approval-mozilla-beta flag on D189688.

Dianna, can I get the approval without the request? Though I am not sure the proper process how we request dependent bugs for the approval, this bug needs bug 1852818, so I requested another uplift request in bug 1852818. Thanks!

Flags: needinfo?(dsmith)
Flags: needinfo?(dsmith)
Attachment #9355940 - Flags: approval-mozilla-beta- → approval-mozilla-beta?
Attachment #9355941 - Flags: approval-mozilla-beta- → approval-mozilla-beta?
QA Whiteboard: [qa-regression-triage] → [qa-regression-triage] [qa-triaged]
Flags: qe-verify+

Comment on attachment 9355940 [details]
Bug 1779404 - Rename testing/web-platform/tests/css/css-scroll-anchoring/after-scrollable-range-shrinkage.html. r?botond

Approved for 119.0b6

Attachment #9355940 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9355941 [details]
Bug 1779404 - Re-clamp the last scroll offset before updating new scroll offsets. r?botond

Approved for 119.0b6

Attachment #9355941 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

:hiro could you consider adding a release note nomination on this? https://wiki.mozilla.org/Release_Management/Release_Notes_Nomination
We can include it in the Fx119 release notes

Flags: needinfo?(hikezoe.birchill)

Release Note Request (optional, but appreciated)
[Why is this notable]: It was an issue on a major site (Facebook)
[Affects Firefox for Android]: Yes
[Suggested wording]: Unexpected scroll position jumps on Facebook have been fixed
[Links (documentation, blog post, etc)]: None

relnote-firefox: --- → ?
Flags: needinfo?(hikezoe.birchill)

I couldn't manage to reproduce the issue on my end in order to verify it. I tried on macOS 10.14, macOS 11.6 and on Windows 10 x64 on different Firefox old versions. I followed all the advices mentioned in the comments but had no success reproducing the issue.

Peter da Silva, could you please check if the issue is still reproducible on you end on the latest Firefox Nightly?
You can download it from here: https://www.mozilla.org/en-US/firefox/channel/desktop/
Thanks.

Flags: needinfo?(resuna)

Added to the Fx119 beta release notes and will include in the final release notes for Fx119

relnote-firefox: ? → 119+

(In reply to Hani Yacoub, Desktop QA from comment #171)

I couldn't manage to reproduce the issue on my end in order to verify it. I tried on macOS 10.14, macOS 11.6 and on Windows 10 x64 on different Firefox old versions. I followed all the advices mentioned in the comments but had no success reproducing the issue.

Peter da Silva, could you please check if the issue is still reproducible on you end on the latest Firefox Nightly?
You can download it from here: https://www.mozilla.org/en-US/firefox/channel/desktop/
Thanks.

I can't reproduce it in the nightly on facebook or reddit.

Flags: needinfo?(resuna)

Could you please do one more time verification on Firefox Beta 119.0b6 so we could close this bug?
You can download the latest Firefox Beta from here: https://www.mozilla.org/en-US/firefox/channel/desktop/

Thank you.

Flags: needinfo?(resuna)

Not fixed in 119.0b6. Improved but when I scrolled down far enough in Facebook it started jumping around again.

Flags: needinfo?(resuna)

Possibly it wasn't fixed in the nightly but I just hadn't scrolled down far enough.

Yes, if I scroll down far enough in the nightly (120.0a1 (2023-10-06) (64-bit)) and then scroll up and down a few times it starts jumping again. Sorry about that, but there's still a problem.

:hiro should we reopen this bug based on https://bugzilla.mozilla.org/show_bug.cgi?id=1779404#c177?

Flags: needinfo?(hikezoe.birchill)

It would be nice to open a new bug for the remaining case. Peter, could you please open a new bug? It would be nice to have a STR with about:support. Note that I can't see the issue with the STR in 177. Thanks!

The fact that Hani isn't able to reproduce with the STR in commen 158 makes me suspect Facebook provides slightly different scripts depending on users? I found the STR after I installed Facebook container and uBlock Origin and removed them, maybe it was a trigger? I am totally unsure.

Flags: needinfo?(hikezoe.birchill)

Closing this bug as verified since it was partially fixed and a new bug was filled for the remaining case.
I'll try testing with installing Facebook container and uBlock Origin and removed them and do a follow up on the new bug logged.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-regression-triage] [qa-triaged]
status-firefox119: fixed → verified
Flags: qe-verify+

It's pertially fixed in Facebook in 120. After a while it starts doing the scrolling back and forth thing, but if I move the mouse to the very edge of the central pane, outside the actual messages, and scroll a bit it works and scrolls normally, even better it seems to fix it for the message area and I can scroll normally anywhere in the feed column again.

You need to log in before you can comment on or make changes to this bug.