[Webkit-unassigned] [Bug 280085] Wheel event with preventDefault() and DOM updates not preventing page scroll
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Sep 23 08:54:03 PDT 2024
https://bugs.webkit.org/show_bug.cgi?id=280085
--- Comment #3 from erjona.topalli at oracle.com ---
(In reply to Simon Fraser (smfr) from comment #2)
> This is a purposeful mitigation that is intended to preserve reasonable
> scrolling performance on pages with unresponsive wheel event handlers; if
> work initiated by the wheel event handler takes too long to run, then we
> fall back to the async (non-blocking) scrolling path.
>
> I believe that Chrome also has a mitigation like this.
>
> Does it make sense to have a page design where the page is scrollable, but
> eats scroll events in one area?
Thanks Simon, we did test on latest Chrome (and Edge) and didn't observe this behavior: perceived performance aside, the wheel event.preventDefault() is respected by the browser and the page never scrolls.
Regarding your page design suggestion, where the page scrolls but one area eats the scroll events--that's exactly what we have demonstrated in the CodePen. We find that that one (gray) area in a scrollable page is unable to eat the scroll events all the time, which is the problem. Imagine that gray area is a GoogleMaps-like component where it eats the mouse wheel events and performs a zoom instead. With this problem, the page will scroll instead of zooming inside the component. And there's nothing the developer can do about it.
I understand that performance considerations are important, but I believe the contract is that event.preventDefault() will always suppress the default behavior (page scroll in this case) regardless of execution time. The purposeful mitigation you described feels like an optimization that should only apply in cases where the passive: true flag is used in the addEventListener options. See https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener#using_passive_listeners. What do you think?
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240923/735450ca/attachment.htm>
More information about the webkit-unassigned
mailing list