Bugzilla

[started typing some quick investigation notes before hiro commented; I'll post it in case it's diagnostically useful]

Here's a profile with some scroll logging enabled in about:logging:
https://share.firefox.dev/4gBA87S

In this^ portion of the profile, I think I was dragging the scrollbar down the page, and you can see it working a little bit in the screenshots track (the scroll position advances somewhat), until the scroll position gets yanked back to the top.

Looking at the content process there, it looks like the page is running some JS while we're scrolling, and in particular it's calling `focus()` on particular elements, so maybe that's involved here?

Here in particular, we've got a sample inside of the page's event-handler for some event that the page dispatches called `course.pageItem:updated`; and the page handles that by calling `focus()` on some element:
https://share.firefox.dev/4hU36AZ

Maybe that `focus()` is what's yanking our scroll position back upwards?

If I open the left sidebar, I can see the focus moving across sections as I scroll (to show you visually what part of the page you're in) -- so I wonder if that's related to the explicit `focus()` invocations here... (like the site is focusing the pieces of the sidebar even though it's collapsed -- and because it's collapsed to the top of the page, that's snapping the scroll position back to the top)

[started typing some quick investigation notes before hiro commented, but didn't hit submit until now; I'll still post it here in case it's diagnostically useful]

Here's a profile with some scroll logging enabled in about:logging:
https://share.firefox.dev/4gBA87S

In this^ portion of the profile, I think I was dragging the scrollbar down the page, and you can see it working a little bit in the screenshots track (the scroll position advances somewhat), until the scroll position gets yanked back to the top.

Looking at the content process there, it looks like the page is running some JS while we're scrolling, and in particular it's calling `focus()` on particular elements, so maybe that's involved here?

Here in particular, we've got a sample inside of the page's event-handler for some event that the page dispatches called `course.pageItem:updated`; and the page handles that by calling `focus()` on some element:
https://share.firefox.dev/4hU36AZ

Maybe that `focus()` is what's yanking our scroll position back upwards?

If I open the left sidebar, I can see the focus moving across sections as I scroll (to show you visually what part of the page you're in) -- so I wonder if that's related to the explicit `focus()` invocations here... (like the site is focusing the pieces of the sidebar even though it's collapsed -- and because it's collapsed to the top of the page, that's snapping the scroll position back to the top)

[started typing some quick investigation notes before hiro commented, but didn't hit submit until now; I'll still post it here in case it's diagnostically useful]

Here's a profile with some scroll logging enabled in about:logging:
https://share.firefox.dev/4gBA87S

In this^ portion of the profile, I think I was dragging the scrollbar down the page, and you can see it working a little bit in the screenshots track (the scroll position advances somewhat), until the scroll position gets yanked back to the top.

Looking at the content process there, it looks like the page is running some JS while we're scrolling, and in particular it's calling `focus()` on particular elements, so maybe that's involved here?

Here in particular, we've got a sample inside of the page's event-handler for some event that the page dispatches called `course.pageItem:updated`; and the page handles that by calling `focus()` on some element:
https://share.firefox.dev/4hU36AZ

Maybe that `focus()` is what's yanking our scroll position back upwards?

If I open the left sidebar, I can see some sort of highlight styling moving across sections as I scroll the main page (to show you visually what part of the page you're in) -- so I wonder if that's related to the explicit `focus()` invocations here... (like the site is focusing the pieces of the sidebar even though it's collapsed -- and because it's collapsed to the top of the page, that's snapping the scroll position back to the top)

[started typing some quick investigation notes before hiro commented, but didn't hit submit until now; I'll still post it here in case it's diagnostically useful]

Here's a profile with some scroll logging enabled in about:logging:
https://share.firefox.dev/4gBA87S

In this^ portion of the profile, I think I was dragging the scrollbar down the page, and you can see it working a little bit in the screenshots track (the scroll position advances somewhat), until the scroll position gets yanked back to the top.

Looking at the content process there, it looks like the page is running some JS while we're scrolling, and in particular it's calling `focus()` on particular elements, so maybe that's involved here?

Here in particular, we've got a sample inside of the page's event-handler for some event that the page dispatches called `course.pageItem:updated`; and the page handles that by calling `focus()` on some element:
https://share.firefox.dev/4hU36AZ

Maybe that `focus()` is what's yanking our scroll position back upwards?

If I open the left sidebar, I can see some sort of highlight styling moving across sections as I scroll the main page (to show you visually what part of the table-of-contents you're in) -- so I wonder if that's related to the explicit `focus()` invocations here... (like the site is focusing the pieces of the sidebar even though it's collapsed -- and because it's collapsed to the top of the page, that's snapping the scroll position back to the top)