Use Chrome's Passive Event Listeners

[dtapuska]

Can passive event listeners be used for the added touch listeners?
See https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md

[scottgonzalez]

We certainly can't force that, because the events can be cancelled by the user. We could potentially add support for EventListenerOptions, but I'd rather wait on that.

[RByers]

We certainly can't force that, because the events can be cancelled by the user.

Obviously that's just for client code designed specifically for PEP. On browsers with native PE implementations they couldn't do that (or rather cancelling pointer events doesn't stop scrolling like cancelling touch events does). Is it a goal of PEP to match the native PE implementation behavior as closely as practical?

[scottgonzalez]

Is it a goal of PEP to match the native PE implementation behavior as closely as practical?

Yes. Are you saying we shouldn't pass preventDefault() through to the touch event? That was already there from @azakus' implementation (see a0d41f5#diff-3b5aeb16d85e265fdb40c6063ac62a96R166). This is tied to other logic about whether or not the page is scrolling, but I guess if we just remove that pass through, it wouldn't matter that we don't update the scrolling flag since we shouldn't be changing the scroll behavior anyway.

[RByers]

The standard behavior for PE is that calling preventDefault on a pointer event suppresses the generation of compatibility (mouse/touch) events, but doesn't affect scrolling and so should not be passed down to underlying touch events.

I think that design dates back to before Chrome supported touch-action, and was intentional deviation from the PE spec to permit Polymer to do some things it wanted to do IIRC. If you're running in a browser that supports touch-action (beyond the limited support Safari has), then I think there should be no reason for you (or clients of PEP) to call preventDefault on a touchstart or touchmove event (since event-time control over scrolling is not possible with pointer events by spec). I recall chatting with @azakus about this at one point, but I think it's tricky to come up with something that works well in both browsers with touch-action and those where you need to use the touch-action-attribute hack. You'd need some different code paths for the two. I don't recall the details though, maybe it's not so bad?

Even on a browser without touch-action support, it's wrong to flow calls on PointerEvent.preventDefault to an underlying TouchEvent.preventDefault. You'll still need to call TouchEvent.preventDefault yourself to respect the touch-action value specified in the attribute, but that should be it I think.

It's possible that touchend is a little different here (handling generaiton of click etc.) but I think that's orthogonal to this discussion. You can get the scrolling performance benefit of standard Pointer Events by registering all your touchstart and touchmove listeners as passive.

[RByers]

In case it helps, our PE impl in blink at the moment is very much like a PE polyfill (implemented in terms of the touch and mouse events chromium sends to blink). The specific code for the behavior we're talking about is here.

[scottgonzalez]

Closing due to discovery in #309.