Scrolling jumps back and forth in the Facebook feed
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
People
(Reporter: resuna, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, webcompat:site-wait)
Attachments
(1 file)
286.30 KB,
text/plain
|
Details |
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.
Comment 1•11 months ago
|
||
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.
Comment 2•11 months ago
|
||
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.
Reporter | ||
Comment 3•11 months ago
|
||
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".
Comment 4•10 months ago
|
||
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.
Comment 5•10 months ago
|
||
By now, this has been extensively reported on SUMO and Mozilla Connect as well. What information could help move toward a solution?
Comment 6•10 months ago
|
||
Yes, sure. If someone tries to identify which change caused this issue by using mozregression, it would be super helpful.
Updated•10 months ago
|
Comment 7•10 months ago
|
||
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?
Reporter | ||
Comment 8•10 months ago
|
||
:tnikkel it's not just Facebook. It's also other websites that use the same kind of user interface.
Comment 9•10 months ago
|
||
Support record at least 18 reports so far about this issue. See → https://trello.com/c/00RXtZB4/28-desktop-autoscroll-issue
Comment 10•10 months ago
|
||
One user confirmed that clearing Facebook cache solve the problem.
Comment 11•10 months ago
|
||
(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.
Comment 12•10 months ago
|
||
(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.
Comment 13•10 months ago
|
||
I am guessing that the issue solved by clearing cache is autoscrolling case (e.g. bug 1781145).
Comment 14•10 months ago
|
||
I can also reproduce with layout.css.scroll-anchoring.enabled=false, so scroll anchor appears to be innocent.
Comment 15•10 months ago
|
||
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.
Comment 16•10 months ago
|
||
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".
Comment 17•10 months ago
|
||
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.
Comment 18•10 months ago
|
||
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
Comment 19•10 months ago
|
||
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.
Comment 20•10 months ago
|
||
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.
Comment 21•10 months ago
|
||
Comment 22•10 months ago
|
||
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.
Comment 23•10 months ago
|
||
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.
Reporter | ||
Comment 24•10 months ago
|
||
(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.
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.
I originally thought it was a problem with my mouse, but I replaced it and even bought a different make.
Reporter | ||
Comment 25•10 months ago
|
||
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!
Comment 26•10 months ago
|
||
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.
Comment 27•10 months ago
|
||
(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.
Comment 28•10 months ago
|
||
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?
Comment 29•10 months ago
|
||
(I haven't seen this at all with Twitter/Reddit and I use those fairly frequently)
Comment 30•10 months ago
|
||
(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.
![]() |
||
Comment 31•10 months ago
•
|
||
I can still reproduce this facebook "infinite scroll" in Nightly105a1(20220811190443).
Comment 32•10 months ago
|
||
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).
Comment 33•10 months ago
|
||
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.
Comment 34•10 months ago
|
||
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.
Comment 35•10 months ago
|
||
I think it might be a site issue because I can reproduce this issue on Nightly from 2020-01-01.
Comment 36•10 months ago
•
|
||
Yes, it is known that is can be reproduced in much older builds.
Comment 37•10 months ago
|
||
Then the flag for regressionwindow-wanted should be taken out. Because if it's a site issue then the regression can't be found.
Reporter | ||
Comment 38•10 months ago
|
||
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).
Comment 39•10 months ago
|
||
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).
Comment 40•10 months ago
•
|
||
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.
Reporter | ||
Comment 41•10 months ago
|
||
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.
Comment 42•10 months ago
|
||
(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?
Reporter | ||
Comment 43•10 months ago
|
||
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?
Comment 44•10 months ago
|
||
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.
Comment 46•10 months ago
|
||
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?
Comment 47•10 months ago
|
||
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...
Comment 48•10 months ago
|
||
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.
Comment 49•10 months ago
|
||
(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.
Comment 50•10 months ago
|
||
(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.
Comment 51•10 months ago
|
||
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.
Comment 52•9 months ago
|
||
Updating bug title to clarify that we're using this bug to track the issue affecting the Facebook feed in particular.
Updated•9 months ago
|
Comment 55•9 months ago
•
|
||
(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.
Comment 56•9 months ago
|
||
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.
Updated•9 months ago
|
Comment 58•9 months ago
|
||
(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?
Comment 61•9 months ago
|
||
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.)
Updated•9 months ago
|
Comment 62•9 months ago
|
||
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?
Comment 63•9 months ago
|
||
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.
Comment 64•9 months ago
|
||
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.
Comment 65•9 months ago
|
||
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.
Comment hidden (duplicate) |
Comment 67•9 months ago
|
||
@Wizcraft, could you clarify please where you changed the "infinite scrolling" setting referenced in comments 63-65?
Comment 68•9 months ago
|
||
@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.
Comment hidden (duplicate) |
Comment 70•9 months ago
|
||
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.
Comment 71•9 months ago
|
||
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.
Comment 72•9 months ago
|
||
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.
Comment 73•9 months ago
|
||
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).
Comment 74•9 months ago
|
||
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.
Comment 75•9 months ago
|
||
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;
- Record the current scroll position just before we are trying to apply scroll anchoring if we are in scroll event handlers
- 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.
Comment 76•9 months ago
|
||
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?
Comment 77•9 months ago
|
||
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.
Comment hidden (advocacy) |
Comment 79•9 months ago
|
||
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.
Comment 80•9 months ago
|
||
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.
Comment 81•8 months ago
|
||
(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.
Comment 82•8 months ago
|
||
My browser.cache.disk.capacity has been at 512000 the whole time I have been experiencing this issue.
Comment 83•8 months ago
|
||
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.
Comment 84•8 months ago
|
||
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.
Comment 85•8 months ago
|
||
(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.
Comment 86•8 months ago
|
||
Now this problem is fixed, I think it was a problem of Facebook itself,
Comment 87•8 months ago
|
||
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
Comment 88•8 months ago
|
||
I also still have the problem.
Comment 89•8 months ago
|
||
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.
Updated•8 months ago
|
Comment 90•8 months ago
|
||
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).
Comment 91•8 months ago
|
||
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)
Comment 92•8 months ago
|
||
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.
Comment 93•8 months ago
|
||
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.
Comment 94•8 months ago
|
||
(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!
Comment 95•8 months ago
|
||
(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.
Comment hidden (advocacy, off-topic) |
Comment 97•8 months ago
|
||
I have the issue also. Desktop, wins 10. Firefox.
Comment 98•8 months ago
|
||
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.
Comment 99•8 months ago
|
||
(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.
Reporter | ||
Comment 100•8 months ago
|
||
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.
Comment 101•8 months ago
|
||
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.
Comment 102•8 months ago
|
||
(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.
Comment 103•8 months ago
|
||
(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.
Comment 104•8 months ago
|
||
(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.
Comment 105•7 months ago
|
||
Been doing this for me forever. Still doing it on latest FF build. Glad to know it's not just me.
Comment 106•7 months ago
|
||
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
Comment 107•7 months ago
|
||
Definitely not fixed.
Comment 108•7 months ago
|
||
Just tried FB on Firefox, bounces around like a basketball. Can't see using FF fulltime til this gets fixed.
Comment 109•5 months ago
|
||
This issue is still happening with Firefox 107.0.1 (Linux).
Comment 110•5 months ago
|
||
(In reply to pasik from comment #109)
This issue is still happening with Firefox 107.0.1 (Linux).
YES!
Reporter | ||
Comment 111•5 months ago
|
||
Also happening in Mastodon (ohai.social).
Comment 112•5 months ago
|
||
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.
Comment 113•5 months ago
|
||
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 (...)
Comment 114•5 months ago
|
||
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..
Comment 115•5 months ago
|
||
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.
Comment 116•5 months ago
|
||
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
Updated•5 months ago
|
Comment 117•5 months ago
|
||
Thanks, does setting layout.css.scroll-anchoring.max-consecutive-adjustments=0
in about:config
fix this for you?
Comment 118•5 months ago
|
||
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.
Comment 119•5 months ago
|
||
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.
Comment 120•5 months ago
|
||
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.
Updated•5 months ago
|
Comment 121•5 months ago
|
||
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!
Comment 122•5 months ago
|
||
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.
Comment 123•5 months ago
|
||
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.
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment 126•5 months ago
|
||
»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.
Comment 127•5 months ago
|
||
(In reply to GORENG from comment #126)
»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!
Comment 128•5 months ago
|
||
(In reply to vyrgozunqk from comment #127)
(In reply to GORENG from comment #126)
»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?
Comment 129•5 months ago
|
||
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.
Comment 130•5 months ago
|
||
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.
Comment 131•5 months ago
|
||
(In reply to GORENG from comment #128)
(In reply to vyrgozunqk from comment #127)
(In reply to GORENG from comment #126)
»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.
Comment 132•5 months ago
|
||
(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.
Comment 133•5 months ago
|
||
For me the problem ceased to exist yesterday. I did not update Firefox. Using a Linux OS and no containers.
Comment 134•4 months ago
|
||
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.
Comment 135•4 months ago
|
||
(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.
Updated•4 months ago
|
Comment 136•3 months ago
|
||
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.
Comment 137•17 days ago
|
||
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).
Description
•