Default to passive: true on root document touch scroll blocking event listeners

[dtapuska]

Chromium/Blink would like to propose an intervention where touch scroll blocking event listeners (touchstart and touchmove) added to Document Level objects would default the AddEventListenerOptions passive field to true.

Document Level objects are defined to be the window, document and body.
Touch scroll blocking event listeners are touchstart and touchmove.

Empirically we have determined that over 80% of touch event listeners invoked don't end up preventing scrolling. There are two opt outs that developers can use:

1. Using touch-action
2. Explicitly specifying passive: false

See more details in Document Level Passive Event Listeners Intervention

and #18

[dtapuska]

/cc @teddink, @smaug----, @RByers, @foolip, @BenjaminPoulain

PTAL as I value feedback from everyone.

[smaug----]

So how is this different to #18 ?
or w3c/touch-events#74 ?

[dtapuska]

By placing this in the wicg we are hoping that we can solicit feedback from our colleagues at Microsoft and Apple.

#18 covers more than just this root document intervention it also covers making it by default for everything and making events non-blocking during fling. So this is a concrete implementation of a example used in #18 .

[foolip]

Doing it in this venue makes sense, but showing the changes as a patch in DOM would I think make it easier to review.

[RByers]

Thanks for filing this specific concrete issue Dave. Note that there's also an active intent thread on blink-dev. We'll do the cross-vendor discussion here and bring any conclusions to the intent discussion.

[RByers]

And to be concrete, the precise effect of this change is:

• During addEventListener
  • If type is touchstart or touchmove, AND
  • If passive option is unspecified, AND
  • If target is window, document, document.documentElement or document.body, THEN
  • set passive to true.

[foolip]

Is that any Window, Document or HTMLBodyElement, or some specific ones?

[dtapuska]

1. Any Window
2. Any Document
3. Any node that has target.ownerDocument.documentElement == target
4. Any node that has target.ownerDocument.body == target

In Blink the code is here.

[foolip]

I guess that's if the target is a Node, and using the "node document". That's unambiguous to me, thanks.

@smaug----, thoughts on that?

[RByers]

I've filed this WebKit bug in the hopes that we can get some public signal on whether this is something WebKit would ever consider doing.

[smaug----]

hmm, target.document == target? What does that mean? Or target.document.documentElement == target? Is this only for events dispatched to Window, Document or Body or what?
I thought this was about listeners on Window, Document or Body.

[smaug----]

And does this mean any document, or only documents which have .defaultView != null ?
And any body or only body elements which are in document which has defaultView != null?

[dtapuska]

target is instance of EventTarget to which the addEventListener is being called on. It has nothing to do with dispatch target at all.

[bzbarsky]

target is instance of EventTarget to which the addEventListener is being called on

Sure, but what exactly is target.document? That doesn't make any sense.

I think what you mean is something more like (based on looking at the Blink implementation):

1. Any Window.
2. Any Document.
3. Any node which is the https://dom.spec.whatwg.org/#document-element of its https://dom.spec.whatwg.org/#concept-node-document.
4. Any node which is the https://html.spec.whatwg.org/multipage/dom.html#the-body-element-2 of its https://dom.spec.whatwg.org/#concept-node-document.

[dtapuska]

Yes there was an implicit predicate if target is a node on 2, 3, 4.