Here's an isolated demo: https://codepen.io/GreenSock/pen/YzLZVOz Notice that if you set overscrollBehavior on the body/html and then set the scrollTop of a position: fixed element, suddenly it becomes impossible to scroll the page at all in Safari 16! It's a pretty show-stopping behavior. If you set the position back to absolute before setting scrollTop and then switch it back to position fixed, that seems to work. Obviously that shouldn't be necessary.
Created attachment 462405 [details] Reduced testcase The overflow:hidden position:fixed intercepts scrolling (you can still scroll the page when the cursor is outside it).
Are you saying you think this is the correct behavior? It definitely seems way wrong to me, and no other browser behaves this way. Also, once it's "stuck" and then you drag the scrollbar a bit, it becomes "unstuck" so your explanation about intercepting the scroll seems inconsistent at best. Or am I missing something?
No, it's a bug, but your testcase was a little misleading because your fixed element covers the entire viewport. The page is scrollable if your cursor isn't over the position:fixed.
The position:fixed is "trapping" the wheel events incorrectly.
I see. Yeah, I need the full-screen position: fixed element in my use case. Thanks for looking into this.
This happens as a result of adding the overflow's ScrollableArea to the FrameView's scrollable area set, which means we add it to the non-fast scrollable region in ScrollingCoordinator::absoluteEventTrackingRegionsForFrame(). This is fallout from 251454@main.
<rdar://problem/100057532>
Pull request: https://github.com/WebKit/WebKit/pull/4810
Committed 257665@main (b08436732d9d): <https://commits.webkit.org/257665@main> Reviewed commits have been landed. Closing PR #4810 and removing active labels.