The behaviour described in comment 10 is a known issue that affects "heavy" pages (that is, pages that run a lot of script on the main thread or otherwise tie up the main thread with e.g. complex rendering). The reason for it is a bit subtle, but I can try to explain:
- For performance reasons, scrollable elements can be in one of two states: "active" and "inactive". The "active" state is more resource-intensive, so the browser only keeps a scrollable element in the active state when it's currently being scrolled, or has recently been scrolled.
- When a scroll frame is in the inactive state, its representation in the compositor (which handles scrolling among other things) is fairly minimal. It's basically "there's something going on in this area, we need to ask the main thread for more information before we can scroll".
- That request for information has a timeout, set at 400 ms. If the main thread does not respond within the timeout (which can sometimes happen on heavy pages), we scroll anyways based on the limited information we have (which can e.g. mean scrolling the page even if, with the additional info, we would have scrolled the child).
- The "~10 seconds" wait you mention (it's actually 15) is how long we keep a scrollable element active after it stops scrolling, before returning it to the inactive state to conserve resources.
The 400 ms timeout is basically a correctness/responsiveness tradeoff. In many cases, the answer from the main thread would be "go ahead and scroll the thing you were going to scroll anyways", in which case not waiting longer than 400 ms for the answer is a responsiveness win. In other cases, the answer is "no, scroll this other thing instead" or "don't scroll at all", in which case we have a correctness bug.
overscroll-behavior, however, we decided that not honouring it would be an unacceptable correctness bug, so in bug 1425573 we took steps to ensure the "fallback behaviour" would be to not scroll anything in that case.
So, while the behaviour described is expected without
overscroll-behavior, it's not expected with
overscroll-behavior -- so we're still interested in a testcase that demonstrates bad behaviour with
One final note: as part of our Site Isolation project (also called "Fission"), we've had to rearchitect our handling of inactive scrollable elements in a way that ends up avoiding the correctness issue described above, regardless of
overscroll-behavior. This is not released yet, but it can be tried on the Nightly channel by opting into the "Fission (Site Isolation)" nightly experiment in
(It's also possible to opt into the new scrolling architecture without opting into Fission by setting the pref
apz.wr.activate_all_scroll_frames=true. However, please be aware that this is not a well-tested configuration.)