1441690 - At Facebook's www.messenger.com site, some attempts at mousewheel back-scrolling end up "snapping back" & failing to load content

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://www.messenger.com/ (and log in, if you aren't logged in)
 2. Click someone's name on the left, to pick a conversation that's got a good deal of backscroll.
 3. Immediately after step 2: try to use your mousewheel (or trackpad) to scroll up to the backscroll of that conversation.

EXPECTED RESULTS:
"Infinite backscroll" scrolling should happen -- the backscroll content should be populated & become visible/scrollable.

ACTUAL RESULTS:
- No new content is populated.
- Your scroll position immediately snapped back to the very bottom.


Kevin tells me that Chrome is not affected by this (but Firefox is).  (I've tested Firefox, and I haven't tested Chrome but I'll trust his report that it's unaffected)

It looks like Facebook has implemented their own scrollbars here, so there might be some complicated ping-ponging of events going on here, and we're violating one of their expectations about the scroll events we send, or something...

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (note: I am furiously trying to mousewheel-scroll upwards, for the entire first ~4 seconds)

Comment 2

[Benoit Girard (:BenWa)]

I've been trying to get Facebook to use APZ as much as possible. Looks like Facebook is calling preventDefault based on the subpar performance I'm seeing. Likely if we fixed that this bug would go away.

Feel free to make a platform change on your side if you think it's impactful but from Facebook's perspective this is better fixed on our side to get full APZ performance. As long as the team doesn't come back to me with a strong reason for having their own scroll bars.

I'll update once someone has cycles to investigate this further.

Comment 3

[Daniel Holbert [:dholbert]]

Thanks, BenWa! That's good context to have here.

(I don't understand enough about what's going wrong here to know whether it's possible to address this with a platform change on our end.  But if it does end up being possible & if Facebook can't get to this right away, we might want to do something, because this is pretty painful in Firefox right now.)

Comment 4

[Botond Ballo [:botond]]

I can repro the issue. It's not a great experience, to be sure :/

Comment 5

[Botond Ballo [:botond]]

Attachment: Stack trace of JS code triggering the jumps back to bottom

The jump back down to the bottom is caused by a scroll offset update triggered by JS code in the main thread.

Attached is the stack trace for the JS code that's triggering the jump. While iIt's hard to tell exactly what the code is trying to code because it's minified and most identifiers are obfuscated, based on the method names "handleResize()", "trackBottomIfRequired()", and "scrollToBottom()", it would seem that the JS code is trying to keep the scrollframe scrolled to the bottom as new content is inserted at the top (representing older comments). Presumably it's doing so because it believes we are scrolled to the bottom, not realizing the visual (async) scroll position has changed.

Markus pointed out that the suggestion described in the attachment in bug 1268140 comment 2 (basically, a more aggressive version of bug 959793 that applies to scrollTo (and scrollTop=x etc.) as well as scrollBy) would solve this problem and many others like this.

I'm not sure if a simpler / more targeted fix can be made on the platform side. Knowing some more details about how "trackBottomIfRequired()" is intended to work may point to a more targeted fix, or allow us to make a suggestion for a more targeted change on the site's side.

Comment 6

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #5)
> I'm not sure if a simpler / more targeted fix can be made on the platform
> side. Knowing some more details about how "trackBottomIfRequired()" is
> intended to work may point to a more targeted fix, or allow us to make a
> suggestion for a more targeted change on the site's side.

ni?BenWa for this (if you think it's a direction that may be worth pursuing).

Comment 7

[Benoit Girard (:BenWa)]

Had a quick look and it wont be trivial to restore the normal scrollbar however I still think its the right thing. I can cycle back later to give an update but it wont be soon I don't think.

Comment 8

[Botond Ballo [:botond]]

(In reply to Benoit Girard (:BenWa) from comment #7)
> Had a quick look and it wont be trivial to restore the normal scrollbar
> however I still think its the right thing. I can cycle back later to give an
> update but it wont be soon I don't think.

I don't think the problem is related to the scrollbar. It seems to be related to the adjustment of the scroll position from JS code after lazy loading of older messages.

Comment 9

[Kevin Hsieh]

This bug is causing users to leave Firefox. At least, the users around me (i.e., college students who use Messenger a lot).

Comment 10

[Benoit Girard (:BenWa)]

Ahh ok, I was looking at the wrong thing then. If it's a Gecko issue then it's probably best to investigate into that. But I'm happy to consider shipping a work around if you find one.

Comment 11

[Botond Ballo [:botond]]

(In reply to Benoit Girard (:BenWa) from comment #10)
> Ahh ok, I was looking at the wrong thing then. If it's a Gecko issue then
> it's probably best to investigate into that. But I'm happy to consider
> shipping a work around if you find one.

Any chance you could get someone familiar with the "trackBottomIfRequired()" function to post a summary of how it's intended to work? It's hard to understand and suggest a workarounnd with the source code minified.

Comment 12

[Kevin Hsieh]

I tried testing several browsers and I can reproduce the issue on Firefox (always), Safari (by scrolling slowly), and IE/Edge (somewhat inconsistently)--just not Chrome. I think maybe BenWa was looking in the right direction in terms of getting at the origin of the bug, though Firefox is by far the most affected browser.

Comment 13

[Botond Ballo [:botond]]

To be clear, this is not a recent Firefox regression. It is technically a regression from APZ, but APZ has been shipping since Firefox 48. Assuming people started seeing this problem recently (otherwise, I imagine, it would have been filed sooner), it must have been introduced by a recent change to the Messenger website that interacts poorly with APZ.

Comment 15

[Benoit Girard (:BenWa)]

Just did a follow-up to see if we can get a fix out for this. Will update when I have details.

Comment 16

[Botond Ballo [:botond]]

There is a platform change we are contemplating that we expect will solve this, tracked in bug 1453425.

However, it's somewhat involved and the timeline for it is unclear, so I would encourage Facebook to continue pursuing a fix on their side in the meantime.

Comment 17

[Chris More [:cmore]]

This happens to be constantly and it is really annoying. Annoying enough that I wasn't dedicated to keeping messenger.com as a pinned app, I would stop using it on desktop. Let me see if I can help get this on FB'd radar.

Comment 18

[Ryan Hunt [:rhunt]]

Bug 1453425 is now enabled in nightly and should resolve this issue.

If anyone is still seeing this with 'apz.relative-update.enabled=true' on Nightly, please let me know and I can investigate further.

Comment 19

[Chris More [:cmore]]

This is still impacting me on release channel 64. Like I said earlier, this is enough of an annoyance to not use Firefox desktop for Messenger.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

It should be fixed on Nightly, if you're willing to try that and let us know it would be much appreciated. Or you could wait until Firefox 65 is released which should also have the fix. But if it's not fixed in that you'll have to wait even longer for it to get fixed for reals.

Comment 21

[Chris More [:cmore]]

Ah, ok! I didn't know what train it is on. Will test

Comment 22

[Chris More [:cmore]]

(In reply to Kartikaya Gupta (away Jan 12-26; email:[e-mail]) from comment #20)

It should be fixed on Nightly, if you're willing to try that and let us know it would be much appreciated. Or you could wait until Firefox 65 is released which should also have the fix. But if it's not fixed in that you'll have to wait even longer for it to get fixed for reals.

oh wow...Firefox 66 nightly on messenger.com is finally nice to use and not constantly annoying. :) Just to confirm confirm that this is on the Firefox 65 train to be released on Jan 29th? I would imagine this is fixed on beta, which is also on 65.

Comment 23

[Kartikaya Gupta (email:[e-mail])]

Yes, Jan 29th is the scheduled release date, and it is currently on beta.

Comment 24

[Panos Astithas (he/him) [:past] (please ni?)]

I have a similar problem that I wonder if I should file separately. In macOS Nightly (and for a long time now), scrolling forward using the touchpad is super janky and slow. If you scroll back in a relatively long conversation (which works fine) and then attempt to scroll forward, scrolling appears to be snapping in various elements for some reason.

Comment 25

[Botond Ballo [:botond]]

(In reply to Panos Astithas (he/him) [:past] (please ni?) from comment #24)

I have a similar problem that I wonder if I should file separately. [...]

Please do. It sounds like you might be running into a different problem, possibly related to scroll anchoring.

Comment 26

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Botond Ballo [:botond] from comment #25)

Please do. It sounds like you might be running into a different problem, possibly related to scroll anchoring.

Filed bug 1568098.

Comment 27

[Botond Ballo [:botond]]

Based on comment 22, it sounds like this issue as originally reported has been fixed in Firefox 65 and later (with a different issue impacting messenger.com being tracked in bug 1568098 / bug 1599627).