When listening to the ‘wheel’ or ‘mousewheel’ event on the document, if the event’s original target element is removed from the DOM the wheel event is no longer dispatched. 1. Add a listener for ‘wheel’ on the document that removes the target of the event from the DOM. Have this happen after the element moves a specific amount or a certain number of events is received. 2. Scroll on the page (over the relevant element) 3. Keep scrolling You will observe that the DOM event is no longer dispatched.
<rdar://problem/19732211>
Created attachment 259762 [details] Patch
Comment on attachment 259762 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=259762&action=review > Source/WebCore/page/mac/EventHandlerMac.mm:919 > + return false; Frames can be removed... > Source/WebCore/page/mac/EventHandlerMac.mm:922 > + return true; Anonymous nodes can't be scrollable? (probably true) > Source/WebCore/page/mac/EventHandlerMac.mm:925 > + return true; What if a node is moved around in the DOM? (removed and reinserted before we get here) Is that OK?
Comment on attachment 259762 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=259762&action=review >> Source/WebCore/page/mac/EventHandlerMac.mm:925 >> + return true; > > What if a node is moved around in the DOM? (removed and reinserted before we get here) Is that OK? It does seem like it would be a problem if we removed a node from one scrolling container, and inserted it into a new location. In that case, even with this code, we would start our event handling with this "migrated" node. Maybe it would be better to just break the caching state in Element::removedFrom.
Created attachment 259786 [details] Patch
Created attachment 259797 [details] Patch
Comment on attachment 259797 [details] Patch r=me
Committed r188920: <http://trac.webkit.org/changeset/188920>