Open Bug 1779404 Opened 5 months ago Updated 21 days ago

Scrolling jumps back and forth in the Facebook feed

Categories

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

Firefox 102
defect

Tracking

()

People

(Reporter: resuna, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: regression, webcompat:site-wait)

Attachments

(1 file)

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.

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.

Attached file anchorlog.txt

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.

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.

(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.

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.

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