Perf: Do not add document-level blocking touch listeners

[ebidel]

All polymer apps get a touch listener added to document by default?

Doing so is typically frowned upon b/c it can have negative effects on page load and scrolling perf, especially on mobile. What are these events for? Can they be passive events by default...or can we have users opt-into passive events somehow if they know they're not going to call preventDefault()?

https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md

cc @RByers @azakus

[RByers]

Back in the day I know @azakus worked to ensure this wasn't necessary (it was the main original concern from abarth@ about the PointerEventPolyfill IIRC). We're pretty close to forcing all touch listeners on the document to be passive by default anyway - you can enabled this in chrome://flags, and I haven't noticed any issues with polymer. So perhaps it's easy to just make these listeners passive?

[eduardosada]

What can we do about this? Any idea?

[esd100]

What is going here and why is there no final answer?

I'm getting thousands of console warnings:
Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive.

[bennypowers]

Is this the _globalOnClick listener in iron-location?

[Thkasis]

Just wondering if there's any updates on this?!