Intent to Intervene: Document Level Passive Event Listeners

[Dave Tapuska]

Contact emails

dtap...@chromium.org

Spec

https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit?disco=AAAAAsxZ9FU

Summary

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.

Motivation

Initially launched as a finch trial (Canary/Dev); this intervention reduces the 99th percentile of scroll start time by 39%.

Most touch scroll blocking event listeners don't end up blocking scroll.~98% of event listeners that are on a root node don't end up blocking scrolling (details in spec).

The finch trial has produced great benefits in the proportion of non-blocking event listeners invoked on the page, which has jumped from 29% to 73%.

Interoperability and Compatibility Risk

There are two opt outs available for developers:

1) Specify touch-action.

2) Pass {passive: false} into the event listener options.

Breakage is known to be less than 2% of events dispatched; our metrics overestimate by not taking into the usage of touch-action being set. We expected the breakage to be much less and this has been demonstrated in canary/dev with the low report of issues seen. There were two reported pages out of our finch experiments. Both are fixable by using touch-action; one landed a fix in production last week.

In terms of developer rationality, it is a little odd that adding a listener on a root node behaves slightly differently than on a node further down in the document. Ideally we'd like to treat all touch event listeners as passive on the entire document but this has much higher risk of breakage, and will require gathering additional data. This launch will contribute data to this effort.

Ongoing technical constraints

No.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

crbug.com/625675

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5093566007214080

Requesting approval to ship?

Yes

[Rick Byers]

I wanted to add that I'm really excited about this intervention.  I've personally been running with chrome://flags/#document-passive-event-listeners enabled for months and find it a substantial net user experience improvement (eg. scrolling on sites like Twitter feel noticeably better than their Android native app equivalent, and serious breakage is anecdotally rare).  When sites do break it's typically in a pretty subtle (but hard to quantify via UMA) fashion.

Also after there being a ton of outreach (including in the Google I/O web keynote talk) for passive touch listeners, I'm convinced that most developers would prefer that we make passive the default for touch with the easy-to-use fix of applying 'touch-action' where needed rather than ask them to do the harder job of opting-in to passive at every point their page installs a touch listener. We still need to get good developer guidance published on this to make it as easy as possible to understand and correct any breakage, but I'm sure the team will be able to get that published before this intervention hits stable.

All that said, it's still a non-trivial trade off to make (and I'm highly biased) - so I'm looking forward to hearing the opinion of API owners.

On Mon, Oct 17, 2016 at 3:00 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org

Spec

https://docs.google.com/document/d/1II7oSIpd8pK91V5kEM3tDLKcIj398jOJn8Niqy6_loI/edit?disco=AAAAAsxZ9FU

Depending on the results of this intervention, we're also talking with other vendors about modifying the TouchEvents specification for this.

[Kenneth Russell]

I'm concerned about the possibility of breaking content. http://crbug.com/639433 is an example of a high-profile web site which posted a neat scientific article that no longer works with this intervention. Is there evidence that developers are updating their content to handle the new requirements?

Thanks,

-Ken

[Philip Jägenstedt]

I've had a look at the doc and the implementation, and I think this makes sense.

My only concern is that this amounts to a change in DOM's addEventListener, and I don't think we should commit to shipping that long term without some buy-in from other implementers. You've already done a finch trial and expect (right?) this change to be permanent, so I think we should treat it like an Intent to Ship.

I think the spec change would be a tweak of the IDL and in https://dom.spec.whatwg.org/#event-flatten-more. WDYT?

[Rick Byers]

There's some discussion about how to spec this with other vendors here and here (and I know there was discussion with Anne somewhere, but I can't find it at the moment).  My opinion was that we should see if this experiment is successful (there's still a non-trivial chance we'll be surprised by breakage and have to revisit) before worrying about how to spec it.   I think it's important that we try to follow the intervention design guidelines in this case, so I do think there's value in trying to follow the process even if we quickly graduate it from an intervention to a full standard :-).  Thoughts?

[Dave Tapuska]

Ideally we need to track what percentage of pages that call preventDefault and don't have a touch action state set. I'm working on this separately. 

This would lead us to know whether the ultimate goal to make the default be passive: true for all nodes is achievable. 

But I didn't want to muddle the ultimate goal and our direction in the next quarters in this intent. 

Dave

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Alexandre Elias]

I just wanted to put in a word of support.  In my opinion, this intervention is the single highest-impact thing we can do to improve scroll responsiveness on Chrome for Android right now.  It completely addresses pathological delays in scroll response in the magnitude of *seconds*.  In practice, whenever I hear a user complaint about scroll latency, it's due to one of these handlers (in combination with a indigestible main-thread workload).  We have many other projects attacking the main-thread workload side, but at the same time we also need to keep pushing on scroll performance isolation, which means eliminating non-passive handlers.

As for compatibility, this will cause a certain amount of breakage but the magnitude is surprisingly low given how many pages have one of these handlers.  The reason is that the vast majority of them are actually intended to be passive from the beginning.  They are either used for passively logging user interaction, or within a non-scrollable document (e.g. the latter is why a site like Google Maps is not broken by this).  This intervention helps establish a "pit of success" where the default behavior has the best performance while still working just fine for most use cases.

[Philip Jägenstedt]

In those issues, I see only a Gecko engineer weighing in, with some concerns. How about WebKit and Edge?

We've had two Intents to Intervene so far, Improved policy for blocking expensive tasks and cross origin iframes require user gesture for Web Audio on Android, handling both roughly as intent to ship.

The first was a scheduler change, if it is web exposed I'm not sure which spec covers it. For the Web Audio change, the spec discussion was in progress and the spec change has since been made.

Concretely, I think there should be an open DOM PR for this that matches what we intend to ship. Ask Microsoft on www-dom and/or publish a copy of the output wherever they'd engage.

I would be nice to hear something like "this looks a bit funny, but if the user benefit is as big as you say and if you manage to ship it to stable, let's merge it to the spec and we'll eventually try to ship it too."

[Dave Tapuska]

What can I do to ensure there is progress on this before the feature freeze the end of this week? I've tried to engage other vendors here: https://github.com/WICG/interventions/issues/35 and formally indicate what we are doing.

dave.

[Dave Tapuska]

The DOM PR request has been open for a few days now and I have just uploaded some rudimentary text for the touch events spec under this pull request. 

I hope that I have spec'd our intents sufficiently in the PR requests enough to proceed.

dave.

[Rick Byers]

Thanks Dave.  This seems like enough to me to give this experiment a try.  Philip, WDYT?

[Philip Jägenstedt]

We still have no really positive signals from other vendors. Mozilla folks are engaged but mainly pointing out (effectively) that it's unfortunate to teach addEventListener about specific event types and targets. There's no getting around that AFAICT, but at least an reluctant "if this works for you we won't mind changing the spec" would be nice.

Can you ping relevant people from Apple and Microsoft again on https://github.com/WICG/interventions/issues/35 and ask for feedback there and/or the two PRs?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

OK, so there's been some discussion in the various issues and PRs today. It would have been good to start that process earlier, but I agree that it'd be sad to miss M56 for a slightly reduced risk. The high-level idea has been out there for a while now, and I can't see a fundamentally different design (layering) that'd still solve the problem.

So, LGTM1, while continuing to discuss and being open to change, even radical change. The nature of this is such that reverting or changing it should be lower risk than e.g. reverting a whole new API, and in fact as I understand it evolving the intervention to include more cases is the hope.

[Rick Byers]

Thanks Philip.  In case anyone else is interested, there's more discussion of this one here.

Dave, since this is an experiment, can you follow-up on this thread at some point in (say) the next 6 months with the status / results?  I think we all agree that we're not done here until we can really close the intervention issue.  I think that includes that we've shown it's highly web compatible (with more concrete data from our ship), specs are updated to reflect it, we've got interop with at least one other engine, etc.  Or, of course, that the experiment has failed and we've reverted / redesigned it (an outcome that is also OK - we can't push things forward without being willing to try things that might fail).

Any other API owners want to weigh in?

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

On Thu, Nov 10, 2016 at 8:17 AM, Rick Byers <rby...@chromium.org> wrote:

Thanks Philip.  In case anyone else is interested, there's more discussion of this one here.

Dave, since this is an experiment, can you follow-up on this thread at some point in (say) the next 6 months with the status / results? 

This is a good idea. Let's review again in 6 months to see how it worked out in practice, both in terms of real-world impact (positive or negative) on sites and users, and what other vendors think about following our lead or not. This will help us to understand what happened with this change, and also inform future changes that might have similar risk.

LGTM2,

I'd also like to say that I really like this change and think it will have a big impact on the web! Thanks for the hard work getting this done, these are important but grungy changes to the platform.

[Dave Tapuska]

Yes I will closely watch the metrics and provide feedback to this group of what we see in stable.

dave.

[Dave Tapuska]

Still waiting on the last approval. Bueller, Bueller, Bueller ?

...

[Jochen Eisinger]

lgtm3