Interacting/scrolling pages on iOS is often a terrible experience because the page has poorly performing synchronous touch event handlers. This proposed intervention makes document-level listeners passive by default (meaning they can't call preventDefault to stop scrolling). https://github.com/WICG/interventions/issues/35 https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit https://github.com/whatwg/dom/issues/365
<rdar://problem/33164597>
See also https://github.com/w3c/touch-events/issues/74 If WebKit ships the same behavior as Chromium then I will argue for updating the touch events spec to define it.
More details (and some of the debate) here: https://groups.google.com/a/chromium.org/d/msg/blink-dev/BW3qrkisqIs/v5Au-HVTAwAJ In particular, note the detailed behavior description: Touch Scroll blocking (touchstart, touchmove) event listeners are treated as passive="true" if added to a root node (window, document, body) and if AddEventListenerOptions passive is not specified. Are you planning on doing the same (window, document and body) or just "document"? Also be sure not to apply this to "touchend" (just start/move). Cancelling touchend is important for suppressing click events etc. (eg. sites relying on old fastclick libraries).
We'll follow you.
*** Bug 164016 has been marked as a duplicate of this bug. ***
Created attachment 318847 [details] Patch
Created attachment 318849 [details] Patch
Comment on attachment 318849 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318849&action=review > Source/WebCore/ChangeLog:12 > + now in the DOM specification: This doesn't seem to be in the DOM spec yet. It still has passive as having a default value of false. > Source/WebCore/ChangeLog:19 > + If the event listener explicitly defines "passive" to false in their > + options dictionary, then the behaviour is overridden. This sentence took me a while to figure out what you mean by "the behavior". > Source/WebCore/dom/EventTarget.cpp:72 > + std::optional<bool> passive = options.passive; You could use auto here.
Comment on attachment 318849 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318849&action=review >> Source/WebCore/ChangeLog:19 >> + options dictionary, then the behaviour is overridden. > > This sentence took me a while to figure out what you mean by "the behavior". Yeah. Which behavior; the "passive by default", or do you override the request for passive=false? > Source/WebCore/ChangeLog:24 > + NOTE: Any fallout from this bug should be collected in: > + https://bugs.webkit.org/show_bug.cgi?id=175869 > + Please do not revert this change just because a site is broken. We'll > + gather the issues and see if we can evangelise or detect via code. Seem weird to put this in the changelog. > Source/WebCore/dom/EventTarget.cpp:79 > + if (auto* node = toNode()) { > + if (node->isDocumentNode() || node->document().documentElement() == node || node->document().body() == node) > + passive = true; > + } else if (toDOMWindow()) > + passive = true; Maybe flip these around because the toDOMWindow check is cheaper than the node-related checks. > LayoutTests/fast/events/touch/ios/passive-by-default-on-document-and-window.html:98 > +<div style="height: 500vh"> > + This is a tall element to make sure there is something to scroll. > +</div> Lame. Just style the body with height. > LayoutTests/fast/events/touch/ios/passive-by-default-overridden-on-document-and-window.html:98 > +<div style="height: 500vh"> > + This is a tall element to make sure there is something to scroll. > +</div> Lame.
Comment on attachment 318849 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318849&action=review > Source/WebCore/ChangeLog:15 > + https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit Any devtools warnings? I know we generate them in chromium to help developers.
Comment on attachment 318849 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=318849&action=review >> Source/WebCore/ChangeLog:12 >> + now in the DOM specification: > > This doesn't seem to be in the DOM spec yet. It still has passive as having a default value of false. Fixed. >> Source/WebCore/ChangeLog:15 >> + https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit > > Any devtools warnings? I know we generate them in chromium to help developers. We'll do that in a separate bug. >>> Source/WebCore/ChangeLog:19 >>> + options dictionary, then the behaviour is overridden. >> >> This sentence took me a while to figure out what you mean by "the behavior". > > Yeah. Which behavior; the "passive by default", or do you override the request for passive=false? I made this more clear - you get a non-passive listener. >> Source/WebCore/ChangeLog:24 >> + gather the issues and see if we can evangelise or detect via code. > > Seem weird to put this in the changelog. I want to make sure that, in 3 months time, when we autospade a regression, we know what to do with it. >> Source/WebCore/dom/EventTarget.cpp:72 >> + std::optional<bool> passive = options.passive; > > You could use auto here. Fixed. >> Source/WebCore/dom/EventTarget.cpp:79 >> + passive = true; > > Maybe flip these around because the toDOMWindow check is cheaper than the node-related checks. Fixed. >> LayoutTests/fast/events/touch/ios/passive-by-default-on-document-and-window.html:98 >> +</div> > > Lame. Just style the body with height. Fixed.
Committed r221092: <http://trac.webkit.org/changeset/221092>
See https://bugs.webkit.org/show_bug.cgi?id=182521 for discussion of the fall-out of shipping this without also shipping touch-action.
Mass move bugs into the DOM component.