Intent to Ship: add EventListenerOptions.passive

[Dave Tapuska]

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/CuOrg2TrnDw/gTgLL59PAQAJ

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

Yes; Touch Events are available today (with the experimental web platform features flag on).

Mouse wheel support for passive event listeners is blocked on using gesture scrolls events. This is enabled via the --enable-wheel-gestures command line flag; but this option should be enabled on Windows and Linux in the near future. Minor fixes need to be done on Android WebView and on Mac. But the benefits for touch should not be blocked on the implementation for the remaining wheel benefits.

Demo link

http://dtapuska.github.io/passive/wheel-passive.html

http://dtapuska.github.io/passive/touch-passive.html

Debuggability

Debuggability is the same as other EventListeners. Although areas that add passive listeners that don't block scroll will not be present in the "show scrolling perf issues" overlay.

Interoperability and Compatibility Risk

Low risk in terms of interoperability and compatibility; this is an opt in feature.

OWP launch tracking bug

http://crbug.com/489802

Entry on the feature dashboard

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

[Rick Byers]

On Thu, Feb 18, 2016 at 3:55 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Studying these histograms (sorry google-internal only), we can say that on Android roughly a third of all touch events are blocking scrolling unnecessarily, and in 10% of those cases we could save >100ms of latency by eliminating the need to block (and in 1% it's a whopping 500ms+).  That's a HUGE potential scroll performance benefit - although (for now) it'll depend on getting authors to opt-in.  I've done some outreach to popular libraries (eg. here) and have anecdotal evidence to suggest that getting even one of these libraries to use passive touch listeners may result in a non-trivial improvement in our overall scroll performance metrics.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/CuOrg2TrnDw/gTgLL59PAQAJ

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

Yes; Touch Events are available today (with the experimental web platform features flag on).

Mouse wheel support for passive event listeners is blocked on using gesture scrolls events. This is enabled via the --enable-wheel-gestures command line flag; but this option should be enabled on Windows and Linux in the near future. Minor fixes need to be done on Android WebView and on Mac. But the benefits for touch should not be blocked on the implementation for the remaining wheel benefits.

Demo link

http://dtapuska.github.io/passive/wheel-passive.html

http://dtapuska.github.io/passive/touch-passive.html

Debuggability

Debuggability is the same as other EventListeners. Although areas that add passive listeners that don't block scroll will not be present in the "show scrolling perf issues" overlay.

Note that we still really need to get scroll latency exposed in dev tools so developers can reason about and easily see the benefits here.

There's also now a slightly hacky way to measure the benefit of this from JS, but we're exploring something better.

Interoperability and Compatibility Risk

Low risk in terms of interoperability and compatibility; this is an opt in feature.

Note that there is some interop risk here.  Believe WebKit may be interested in this feature, but no real strong public signals from Mozilla and Edge.  From private conversations, I expect all the vendors to play a bit of a "wait and see" here (I've said we'll share some perf stats about the benefits pages are getting from this).  In particular, there's an argument that says we should require web developers to switch to Pointer Events if they want this perf benefit for touch scrolling.  Personally (although I believe in Pointer Events) I think it's desirable to separate those concerns.

[Kenji Baheux]

Non-owner thumbs up:

• From performance deep dives, we learned that the usage of (active) event listeners by third parties is a major source of performance issues.
  
• A passive flavour would be sufficient for most if not all third party use cases.

[Philip Jägenstedt]

Dave, Rick, do you know of any libraries or web properties that have already begun to experiment with this? https://www.chromestatus.com/metrics/feature/timeline/popularity/968 has begun to rise and if it isn't because of this it could be bad news.

--
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+...@chromium.org.

[Sami Kyostila]

A big +1 for doing this.

pe 19. helmikuuta 2016 klo 6.19 Philip Jägenstedt <phi...@opera.com> kirjoitti:

Dave, Rick, do you know of any libraries or web properties that have already begun to experiment with this? https://www.chromestatus.com/metrics/feature/timeline/popularity/968 has begun to rise and if it isn't because of this it could be bad news.

On Fri, Feb 19, 2016 at 4:54 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 18, 2016 at 3:55 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Studying these histograms (sorry google-internal only), we can say that on Android roughly a third of all touch events are blocking scrolling unnecessarily, and in 10% of those cases we could save >100ms of latency by eliminating the need to block (and in 1% it's a whopping 500ms+).  That's a HUGE potential scroll performance benefit - although (for now) it'll depend on getting authors to opt-in.  I've done some outreach to popular libraries (eg. here) and have anecdotal evidence to suggest that getting even one of these libraries to use passive touch listeners may result in a non-trivial improvement in our overall scroll performance metrics.

That's a really interesting statistic. I wonder if we should be doing more to convince developers switch to passive listeners. Something like a devtools warning or a console message?

[Alex Komoroske]

On Fri, Feb 19, 2016 at 3:00 AM, Sami Kyostila <skyo...@chromium.org> wrote:

A big +1 for doing this.

pe 19. helmikuuta 2016 klo 6.19 Philip Jägenstedt <phi...@opera.com> kirjoitti:

Dave, Rick, do you know of any libraries or web properties that have already begun to experiment with this? https://www.chromestatus.com/metrics/feature/timeline/popularity/968 has begun to rise and if it isn't because of this it could be bad news.

On Fri, Feb 19, 2016 at 4:54 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 18, 2016 at 3:55 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Studying these histograms (sorry google-internal only), we can say that on Android roughly a third of all touch events are blocking scrolling unnecessarily, and in 10% of those cases we could save >100ms of latency by eliminating the need to block (and in 1% it's a whopping 500ms+).  That's a HUGE potential scroll performance benefit - although (for now) it'll depend on getting authors to opt-in.  I've done some outreach to popular libraries (eg. here) and have anecdotal evidence to suggest that getting even one of these libraries to use passive touch listeners may result in a non-trivial improvement in our overall scroll performance metrics.

That's a really interesting statistic. I wonder if we should be doing more to convince developers switch to passive listeners. Something like a devtools warning or a console message?

We could also write an in depth blog post or technical article describing the problem and why developers should adopt it. 

[Rick Byers]

On Fri, Feb 19, 2016 at 8:56 AM, Alex Komoroske <komo...@chromium.org> wrote:

On Fri, Feb 19, 2016 at 3:00 AM, Sami Kyostila <skyo...@chromium.org> wrote:

A big +1 for doing this.

pe 19. helmikuuta 2016 klo 6.19 Philip Jägenstedt <phi...@opera.com> kirjoitti:

Dave, Rick, do you know of any libraries or web properties that have already begun to experiment with this? https://www.chromestatus.com/metrics/feature/timeline/popularity/968 has begun to rise and if it isn't because of this it could be bad news.

On Fri, Feb 19, 2016 at 4:54 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 18, 2016 at 3:55 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Studying these histograms (sorry google-internal only), we can say that on Android roughly a third of all touch events are blocking scrolling unnecessarily, and in 10% of those cases we could save >100ms of latency by eliminating the need to block (and in 1% it's a whopping 500ms+).  That's a HUGE potential scroll performance benefit - although (for now) it'll depend on getting authors to opt-in.  I've done some outreach to popular libraries (eg. here) and have anecdotal evidence to suggest that getting even one of these libraries to use passive touch listeners may result in a non-trivial improvement in our overall scroll performance metrics.

That's a really interesting statistic. I wonder if we should be doing more to convince developers switch to passive listeners. Something like a devtools warning or a console message?

We could also write an in depth blog post or technical article describing the problem and why developers should adopt it. 

Yep, I think there's tons to do here and it's going to take some time to achieve the full benefit (eg. I also want to work with APM companies like NewRelic).  I'm also envisioning a "force passive" intervention in our future to replace the touch ACK timeout (which has a similar effect but in a less rational and less useful way).  I've been meaning to write down a sketch of the full strategy here, sorry I haven't done that yet.  But let's not get ahead of ourselves on this thread - it seems clear the next step is to ship this piece, and then iterate on outreach, tooling and functionality.  Happy to brainstorm more over on input-dev if you like...

[Chris Harrelson]

LGTM1

[Jacob Rossi]

Interoperability and Compatibility Risk

Low risk in terms of interoperability and compatibility; this is an opt in feature.

Note that there is some interop risk here.  Believe WebKit may be interested in this feature, but no real strong public signals from Mozilla and Edge.  From private conversations, I expect all the vendors to play a bit of a "wait and see" here (I've said we'll share some perf stats about the benefits pages are getting from this).  In particular, there's an argument that says we should require web developers to switch to Pointer Events if they want this perf benefit for touch scrolling.  Personally (although I believe in Pointer Events) I think it's desirable to separate those concerns.

Forgive me, Rick, because I know we discussed this briefly before and I forget the outcome.

But what about the compat implications that this feature is repurposes the useCapture argument already support  in browsers?  Developers that use this feature in Chrome, will write code like:

    element.addEventListener("touchstart", foo, {capture: false})

In Chrome, this would mean "fire the event during the target/bubbling phase." In all other browsers, this will get interpreted as "fire the event during the capture phase."  It seems to me this design won't gracefully fallback in older browsers because of this, raising a real compat risk.

Test page: http://jsbin.com/dezofudoju/edit?html,js,console,output  

In Edge, Firefox:  event is fired in capture phase

In Chrome only: event is fired in bubble phase

[Dave Tapuska]

Jacob, your discussion is most relevant to Intent to Ship EventListenerOptions where we added the dictionary item in M49.

--

[Jacob Rossi]

On Friday, February 19, 2016 at 10:34:55 AM UTC-8, Dave Tapuska wrote:

Jacob, your discussion is most relevant to Intent to Ship EventListenerOptions where we added the dictionary item in M49.

Yes, they're really intermingled. But this feature is what will likely compel developers to start to use EventListenerOptions since the previous intent didn't actually add new capabilities, hence my concern on the compat. 

[Rick Byers]

On Fri, Feb 19, 2016 at 1:01 PM, Jacob Rossi <jro...@microsoft.com> wrote:

Interoperability and Compatibility Risk

Low risk in terms of interoperability and compatibility; this is an opt in feature.

Note that there is some interop risk here.  Believe WebKit may be interested in this feature, but no real strong public signals from Mozilla and Edge.  From private conversations, I expect all the vendors to play a bit of a "wait and see" here (I've said we'll share some perf stats about the benefits pages are getting from this).  In particular, there's an argument that says we should require web developers to switch to Pointer Events if they want this perf benefit for touch scrolling.  Personally (although I believe in Pointer Events) I think it's desirable to separate those concerns.

Forgive me, Rick, because I know we discussed this briefly before and I forget the outcome.

But what about the compat implications that this feature is repurposes the useCapture argument already support  in browsers?  Developers that use this feature in Chrome, will write code like:

    element.addEventListener("touchstart", foo, {capture: false})

In Chrome, this would mean "fire the event during the target/bubbling phase." In all other browsers, this will get interpreted as "fire the event during the capture phase."  It seems to me this design won't gracefully fallback in older browsers because of this, raising a real compat risk.

Test page: http://jsbin.com/dezofudoju/edit?html,js,console,output  

In Edge, Firefox:  event is fired in capture phase

In Chrome only: event is fired in bubble phase

There was some debate about this when it was being designed 6 months ago, eg. see short summary here.

The conclusion was that this problem is really the same as when any new API is added.  How do developers write code against the new API without their code being broken on browsers that don't support the API?  As always the answer is feature detection and (optionally) relying on a polyfill.  We should probably try to get a feature-detect into Modernizr or other such tools to help with the discovery cost here, and will certainly encourage it's use in all our evangelism for the API.

As with any new API there's a risk that developers won't use a polyfill or test on old browsers and their site will be somehow broken there.  The only difference I see in this case is the specific failure mode when that happens.  Eg. instead of the typical failure of getting an exception due to an undefined property, the call may appear to work with the potentially subtle difference that the listener is incorrectly added as a capturing listener.  I don't see any compelling reason to believe failing hard would be better here.  I.e. are sites really any more likely to be broken by the result of having their listener invoked in the incorrect phase, than by having an unhandled exception?

Although I'm guessing you're suggesting not that we use a different method name, but that we use an API that's forwards compatible - eg. adding a 4th argument and leaving the 3rd alone, right?  There's unfortunately no design that would provide true forwards compatibility here.  Eg. imagine code like 'addEventListener("touchstart", handler, false, true)' for adding a passive listener, but then accidentally calls preventDefault from within the handler somewhere.  On newer browsers that call will be ignored but on older browsers it'll be honored - possibly leading to breakage if the developer never tests on those older browsers.  Given that we didn't want to present an incorrect perception of being forwards compatible we figured it was better to just require the use of feature detection / polyfills than to make the API uglier by requiring but-yet-another argument.

Am I missing some reason to believe that this could be such a big compat problem in practice that we should try to revisit?  It's really quite late to be changing the API now (although I know you mentioned this concern in person at CDS), as Dave said the API change in question has already shipped in Chrome 49.  Regardless I'd love to collaborate on what else we should do to minimize the compat risk here.  Any ideas?  Like I said, I'll make sure our samples and guidance all encourage the use of a polyfill.

Thanks,

   Rick

[smaug]

On 02/19/2016 10:31 PM, Rick Byers wrote:

>
>
> On Fri, Feb 19, 2016 at 1:01 PM, Jacob Rossi <jro...@microsoft.com <mailto:jro...@microsoft.com>> wrote:
>
> Interoperability and Compatibility Risk
>
> Low risk in terms of interoperability and compatibility; this is an opt in feature.
>
>
> Note that there is some interop risk here. Believe WebKit may be interested in this feature

> <https://bugs.webkit.org/show_bug.cgi?id=149466>, but no real strong public signals from Mozilla and Edge. From private

> conversations, I expect all the vendors to play a bit of a "wait and see" here (I've said we'll share some perf stats
> about the benefits pages are getting from this). In particular, there's an argument that says we should require web
> developers to switch to Pointer Events if they want this perf benefit for touch scrolling. Personally (although I believe
> in Pointer Events) I think it's desirable to separate those concerns.
>
>
> Forgive me, Rick, because I know we discussed this briefly before and I forget the outcome.
>
> But what about the compat implications that this feature is repurposes the useCapture argument already support in browsers? Developers that use
> this feature in Chrome, will write code like:
> element.addEventListener("touchstart", foo, {capture: false})
>
> In Chrome, this would mean "fire the event during the target/bubbling phase." In all other browsers, this will get interpreted as "fire the event
> during the capture phase." It seems to me this design won't gracefully fallback in older browsers because of this, raising a real compat risk.
>
> Test page: http://jsbin.com/dezofudoju/edit?html,js,console,output
>
> In Edge, Firefox: event is fired in capture phase
> In Chrome only: event is fired in bubble phase
>
>
> There was some debate about this when it was being designed 6 months ago, eg. see short summary here

> <https://github.com/RByers/EventListenerOptions/issues/12>.

>
> The conclusion was that this problem is really the same as when any new API is added. How do developers write code against the new API without their
> code being broken on browsers that don't support the API? As always the answer is feature detection

> <https://github.com/RByers/EventListenerOptions/blob/gh-pages/explainer.md#eventlisteneroptions> and (optionally) relying on a polyfill
> <https://github.com/RByers/EventListenerOptions/blob/gh-pages/EventListenerOptions.polyfill.js>. We should probably try to get a feature-detect into
> Modernizr <https://github.com/Modernizr/Modernizr/issues/1894> or other such tools to help with the discovery cost here, and will certainly encourage

> it's use in all our evangelism for the API.
>
> As with any new API there's a risk that developers won't use a polyfill or test on old browsers and their site will be somehow broken there. The only
> difference I see in this case is the specific failure mode when that happens. Eg. instead of the typical failure of getting an exception due to an
> undefined property, the call may appear to work with the potentially subtle difference that the listener is incorrectly added as a capturing
> listener. I don't see any compelling reason to believe failing hard would be better here. I.e. are sites really any more likely to be broken by the
> result of having their listener invoked in the incorrect phase, than by having an unhandled exception?
>
> Although I'm guessing you're suggesting not that we use a different method name, but that we use an API that's forwards compatible - eg. adding a 4th
> argument and leaving the 3rd alone, right? There's unfortunately no design that would provide true forwards compatibility here. Eg. imagine code
> like 'addEventListener("touchstart", handler, false, true)' for adding a passive listener,

A bit off topic, but Gecko actually handles the 4th param in a special way. It affects whether untrusted events are handled.
Yes, I know, bad to expose that to the web, but it was added ages ago.

but then accidentally calls preventDefault from within the
> handler somewhere. On newer browsers that call will be ignored but on older browsers it'll be honored - possibly leading to breakage if the developer
> never tests on those older browsers. Given that we didn't want to present an incorrect perception of being forwards compatible we figured it was
> better to just require the use of feature detection / polyfills than to make the API uglier by requiring but-yet-another argument.
>
> Am I missing some reason to believe that this could be such a big compat problem in practice that we should try to revisit? It's really quite late to
> be changing the API now

How so. The new API was just added. Better to fix it now and not later. We, "web platform devs", are rather good at shipping less than perfect APIs
and realizing too late the mistakes we've made ;)
We focused too much on backwards compatibility when spec'ing this, and not forwards compatibility.

I think I'm with jrossi here. The risk that pages start to target (even semi-accidentally via some script library updates) browsers which support the
new syntax could mean web pages become broken when used with ESR-like or similar rarely updated browsers.


-Olli

(although I know you mentioned this concern in person at CDS), as Dave said the API change in question has already shipped in
> Chrome 49. Regardless I'd love to collaborate on what else we should do to minimize the compat risk here. Any ideas? Like I said, I'll make sure
> our samples and guidance all encourage the use of a polyfill.
>
> Thanks,
> Rick
>
>
> On Friday, February 19, 2016 at 10:34:55 AM UTC-8, Dave Tapuska wrote:
>
> Jacob, your discussion is most relevant to Intent to Ship EventListenerOptions

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/64DG7iR5Qjs/HHX2unspAQAJ> where we added the dictionary item in M49.

>
>
> Yes, they're really intermingled. But this feature is what will likely compel developers to start to use EventListenerOptions since the previous
> intent didn't actually add new capabilities, hence my concern on the compat.
>
>

> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

[Rick Byers]

Yep, if this is actually important I agree it's better to fix it now than to realize later when it may be too late.

 

We focused too much on backwards compatibility when spec'ing this, and not forwards compatibility.

I think I'm with jrossi here. The risk that pages start to target (even semi-accidentally via some script library updates) browsers which support the new syntax could mean web pages become broken when used with ESR-like or similar rarely updated browsers.

Ok, I've re-opened this issue, shall we continue the design discussion there?  Or is there some better forum where Microsoft can still participate?  If we can come to consensus on a better alternative, I'm happy to try to change it.

[PhistucK]

Also, Chrome 49 is still in beta, not stable. Changes can still happen, especially ones that simply toggle an feature.

☆PhistucK

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

[TAMURA, Kent]

On Fri, Feb 19, 2016 at 5:55 AM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Does it mean only specific input events support passive event listeners?

 

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/CuOrg2TrnDw/gTgLL59PAQAJ

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

Yes; Touch Events are available today (with the experimental web platform features flag on).

Mouse wheel support for passive event listeners is blocked on using gesture scrolls events. This is enabled via the --enable-wheel-gestures command line flag; but this option should be enabled on Windows and Linux in the near future. Minor fixes need to be done on Android WebView and on Mac. But the benefits for touch should not be blocked on the implementation for the remaining wheel benefits.

Demo link

http://dtapuska.github.io/passive/wheel-passive.html

http://dtapuska.github.io/passive/touch-passive.html

Debuggability

Debuggability is the same as other EventListeners. Although areas that add passive listeners that don't block scroll will not be present in the "show scrolling perf issues" overlay.

Interoperability and Compatibility Risk

Low risk in terms of interoperability and compatibility; this is an opt in feature.

OWP launch tracking bug

http://crbug.com/489802

Entry on the feature dashboard

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

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

On Wed, Feb 24, 2016 at 12:14 PM, TAMURA, Kent <tk...@chromium.org> wrote:

On Fri, Feb 19, 2016 at 5:55 AM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org, rby...@chromium.org

Spec

https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive

Tag review not necessary; minor change to existing API.

Summary

Expose "passive" boolean in the EventListenerOptions dictionary. Implement the behaviour with respect to dispatching passive EventListeners so that calling preventDefault inside executing the passive registered callback only generates a warning to the console.

Compositor has been updated to recognize these regions and not block scroll when encountering these passive EventListeners for touch and mouse wheel.

Does it mean only specific input events support passive event listeners?

The processing model in DOM is the same for all events, and guarantees that an event listener registered as passive cannot cancel the event, as preventDefault() will do nothing. But it's only for certain kinds of events that this enables an optimization, like not blocking scroll.

I say LGTM2. It's unfortunate that this will require feature detection to use safely, but it's not a unique situation, and none of the alternatives seem any better to me.

That usage of objects as the third argument is increasing is strange, but with no way to investigate I don't think it would make sense to take a "wait and see" approach. In the worst case that could worsen our chances of shipping later.

Philip

[Dave Tapuska]

The only input events that take advantage will currently be touch and mouse wheel; which are the only raw input events handled by the compositor.

Registering a passive event listener with another input type will just stop you (and log in the console) from having preventDefault() do anything.

But we do reserve the right for other input events to be handled in the compositor in the future. Keyboard events (specifically page up/down) are always on the slow scrolling path and that has always bothered me.

dave.

[TAMURA, Kent]

Thanks.  Now I understand that 'passive' means just 'preventPreventDefault'.  The benefit is obvious.  LGTM3.

[Rick Byers]

On Wed, Feb 24, 2016 at 8:04 PM, TAMURA, Kent <tk...@chromium.org> wrote:

Thanks.  Now I understand that 'passive' means just 'preventPreventDefault'.  The benefit is obvious.  LGTM3.

Hmm, maybe we should have called it that ;-)

Thanks!  Let's give the forwards compatibility debate a couple more days to see if it can be resolved before landing this (meaning we'll slip this from Chrome 50 to Chrome 51 as a result).

[PhistucK]

What about the original EventListenerOptions addition that landed in Chrome 49 (still in beta)? I think it should be reverted for now.

☆PhistucK

[Rick Byers]

On Thu, Feb 25, 2016 at 2:19 AM, PhistucK <phis...@gmail.com> wrote:

What about the original EventListenerOptions addition that landed in Chrome 49 (still in beta)? I think it should be reverted for now.

It's a good question.  The situation is complicated.  tl;dr I think the lowest risk thing to do is to leave EventListenerOptions enabled in M49, but consider disabling it in M50.  See below for details.  I'm happy to disable it if there's consensus that that's somehow lower risk.

The basic EventListenerOptions feature was shipped first to help resolve the (separate but related) concern over backwards compatibility.  The thinking was that people were very unlikely to switch to the new dictionary syntax when the only option is 'capture' (it's strictly more verbose with no benefit, especially once you add the feature detect or polyfill).  We felt that if back compat issues were uncovered from that change, it would give us time to safely change the API before people have a reason to want to use the 'passive' option.

The debate over forwards compat doesn't seem to be any closer to consensus, but there are still a number of DOM experts (including @annevk the spec editor) arguing for leaving things as is.  So here's the risk tradeoffs I see for this decision:

Option A: disable the M49 EventListenersOption support, plan to ship everything in M51

If we ultimately decide to stick with the current design, this will increase the risk that a compat issue will be discovered after a bunch of content has started to use passive listeners.  Although it's unlikely, this would be a pretty terrible outcome IMHO.

Option B: leave things as they are for M49 and M50

If we decide to change designs, we'll have to consider the potential breaking change.  But given:

 - any valid use would need a feature detect to continue working in other browsers (and that feature detect would fail if we change designs)

 - there's no good reason to use the 'capture' option

I believe the risk is low.  In fact, given how new this feature is, I feel quite comfortable myself saying we'll happily break any code that was depending on it without a proper feature detect.

Also by leaving it enabled in M49, there's a chance we'll discover a non-trivial back compat issue and that'll help resolve the forwards compat debate (lending substantial further evidence on the side of changing the API).

Option C: leave in for M49 but disable in M50

This gets us most of the back-compat test value we were going for, while still reducing somewhat the risk of wanting to make a breaking change.  This seems like a reasonable middle ground to me.  

Option D: disable the M49 option and delay the full launch further to mitigate the back compat risk

If we decide to stick with the current design, we could still ship basic EventListenerOptions in M50 and then delay the 'passive' option to M51 or M52 in order to give us enough time to get the back compat data.  Given the large perf benefit available from this feature, I personally don't think the (relatively small) risks we're talking about can justify an additional 6-12 week delay.  Maybe others disagree though?

So I believe we should go with option A for now, and depending on the resolution of the forwards compat debate, consider option C at a later date (we've got nearly 6 weeks to make the decision to disable the feature for M50 stable).

Anyone have any objections to this plan?

[PhistucK]

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

☆PhistucK

[Rick Byers]

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

[Philip Jägenstedt]

On Fri, Feb 26, 2016 at 4:22 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

It's not necessarily a bug, it could be some code that wants capturing behavior and just happens to be using an object as the truthy value. If it's really just on M48 that would be hard to explain by something in the wild, though, an internal page seems more likely. How high is usage on M48? Is it the same for all platforms? Any weekend variability?

Concerning forward compat, there are two issues:

• The more verbose/ugly the feature detection, the less likely it is to be used.
• The more subtle the failure is in non-supporting browsers, the more likely it is to be unnoticed/ignored.

The current design isn't the best in these two regards, it's true. However, lacking an alternative that the people driving this feature (and Anne) think is an overall improvement, I think we should stay the course. In other words, leave EventListenersOptions support in M49, and ship EventListenerOptions.passive in M50, if possible, or M51.

I don't think this is the only reasonable option, but we need to move forward somehow.

Philip

[Rick Byers]

On Fri, Feb 26, 2016 at 12:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Fri, Feb 26, 2016 at 4:22 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

It's not necessarily a bug, it could be some code that wants capturing behavior and just happens to be using an object as the truthy value. If it's really just on M48 that would be hard to explain by something in the wild, though, an internal page seems more likely. How high is usage on M48? Is it the same for all platforms? Any weekend variability?

Looking at this again, we were confused - sorry!  This use counter was added in M48 which went stable around Jan 26 and didn't really get close to peak volume until around Feb 4.  This bump we see in the graph is only because prior to Jan 26 we were looking at a metric only reported by beta channel while still using the total page loads from all channels in the denominator.   The actual value has been holding quite steady over time and across milestones at around 0.02%-0.03% of page loads.  Sorry for the confusion!

[For the pedantic, yes this graph is showing the proportion of FeatureObserver entries with the value in question, which isn't quite the same thing as the proportion of page loads with a particular value.  We divide by the 'PageDestruction' bucket count to get the proportion of page loads, but I verified that PageDestruction holds steady (across this time and milestones) around 4% of all FeatureObserver entries.  So although the absolute value is wrong (not that you can tell from the unhelpful y-axis scale), the representation of the relative change over time as a function of page loads is still valid].

Concerning forward compat, there are two issues:

• The more verbose/ugly the feature detection, the less likely it is to be used.
• The more subtle the failure is in non-supporting browsers, the more likely it is to be unnoticed/ignored.

The current design isn't the best in these two regards, it's true. However, lacking an alternative that the people driving this feature (and Anne) think is an overall improvement, I think we should stay the course. In other words, leave EventListenersOptions support in M49, and ship EventListenerOptions.passive in M50, if possible, or M51.

I don't think this is the only reasonable option, but we need to move forward somehow.

Agreed.  However Jacob has been out on vacation for the past few days, I'd like to try a little more next week to see if we can come to some sort of compromise that he and Olli are OK with.  So at this point we're definitely not shipping passive in M50, and there's still a chance we may want to change the API before shipping in M51.  Given that, do you agree that leaving M49 as-is is still the best choice?  We're nearly out of time to change anything in 49 here.

Philip

[Philip Jägenstedt]

On Sat, Feb 27, 2016 at 2:14 AM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Feb 26, 2016 at 12:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Fri, Feb 26, 2016 at 4:22 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

It's not necessarily a bug, it could be some code that wants capturing behavior and just happens to be using an object as the truthy value. If it's really just on M48 that would be hard to explain by something in the wild, though, an internal page seems more likely. How high is usage on M48? Is it the same for all platforms? Any weekend variability?

Looking at this again, we were confused - sorry!  This use counter was added in M48 which went stable around Jan 26 and didn't really get close to peak volume until around Feb 4.  This bump we see in the graph is only because prior to Jan 26 we were looking at a metric only reported by beta channel while still using the total page loads from all channels in the denominator.   The actual value has been holding quite steady over time and across milestones at around 0.02%-0.03% of page loads.  Sorry for the confusion!

[For the pedantic, yes this graph is showing the proportion of FeatureObserver entries with the value in question, which isn't quite the same thing as the proportion of page loads with a particular value.  We divide by the 'PageDestruction' bucket count to get the proportion of page loads, but I verified that PageDestruction holds steady (across this time and milestones) around 4% of all FeatureObserver entries.  So although the absolute value is wrong (not that you can tell from the unhelpful y-axis scale), the representation of the relative change over time as a function of page loads is still valid].

So disclaimer aside, the value is 0.02%-0.03% if normalized in the same as the chromestatus.com is? That's actually a fairly big number. It's a safe bet that very few happen to be {capture:true}, so pretty much all of these will be a change in behavior from capturing to non-capturing.

 

Concerning forward compat, there are two issues:

• The more verbose/ugly the feature detection, the less likely it is to be used.
• The more subtle the failure is in non-supporting browsers, the more likely it is to be unnoticed/ignored.

The current design isn't the best in these two regards, it's true. However, lacking an alternative that the people driving this feature (and Anne) think is an overall improvement, I think we should stay the course. In other words, leave EventListenersOptions support in M49, and ship EventListenerOptions.passive in M50, if possible, or M51.

I don't think this is the only reasonable option, but we need to move forward somehow.

Agreed.  However Jacob has been out on vacation for the past few days, I'd like to try a little more next week to see if we can come to some sort of compromise that he and Olli are OK with.  So at this point we're definitely not shipping passive in M50, and there's still a chance we may want to change the API before shipping in M51.  Given that, do you agree that leaving M49 as-is is still the best choice?  We're nearly out of time to change anything in 49 here.

I honestly wouldn't have expected such high usage, and if there's anything that could be done to learn something about it before the experiment reaches stable, that would be valuable. It could be a disaster, or it could all be due to a single site that actually works just the same with the inversion of capturing behavior. Would it make sense to let a custom build crawl the top million sites, does that infrastructure exist?

If there's nothing that can be learned before stable, then leaving EventListenersOptions in M49 is the only remaining way to test whether objects as the third argument in existing web content is a deal-breaker. If we don't learn that, in the worst case months could be lost somewhere down the line, so I'd lean towards keeping it in and being very quick to revert if necessary.

Philip

[Rick Byers]

On Sat, Feb 27, 2016 at 1:51 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Sat, Feb 27, 2016 at 2:14 AM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Feb 26, 2016 at 12:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Fri, Feb 26, 2016 at 4:22 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

It's not necessarily a bug, it could be some code that wants capturing behavior and just happens to be using an object as the truthy value. If it's really just on M48 that would be hard to explain by something in the wild, though, an internal page seems more likely. How high is usage on M48? Is it the same for all platforms? Any weekend variability?

Looking at this again, we were confused - sorry!  This use counter was added in M48 which went stable around Jan 26 and didn't really get close to peak volume until around Feb 4.  This bump we see in the graph is only because prior to Jan 26 we were looking at a metric only reported by beta channel while still using the total page loads from all channels in the denominator.   The actual value has been holding quite steady over time and across milestones at around 0.02%-0.03% of page loads.  Sorry for the confusion!

[For the pedantic, yes this graph is showing the proportion of FeatureObserver entries with the value in question, which isn't quite the same thing as the proportion of page loads with a particular value.  We divide by the 'PageDestruction' bucket count to get the proportion of page loads, but I verified that PageDestruction holds steady (across this time and milestones) around 4% of all FeatureObserver entries.  So although the absolute value is wrong (not that you can tell from the unhelpful y-axis scale), the representation of the relative change over time as a function of page loads is still valid].

So disclaimer aside, the value is 0.02%-0.03% if normalized in the same as the chromestatus.com is? That's actually a fairly big number. It's a safe bet that very few happen to be {capture:true}, so pretty much all of these will be a change in behavior from capturing to non-capturing.

I believe so, yes.  We normalize by dividing by the PageDestruction count (though I haven't actually confirmed that this is exactly what the code for chromestatus.com is doing). 

Concerning forward compat, there are two issues:

• The more verbose/ugly the feature detection, the less likely it is to be used.
• The more subtle the failure is in non-supporting browsers, the more likely it is to be unnoticed/ignored.

The current design isn't the best in these two regards, it's true. However, lacking an alternative that the people driving this feature (and Anne) think is an overall improvement, I think we should stay the course. In other words, leave EventListenersOptions support in M49, and ship EventListenerOptions.passive in M50, if possible, or M51.

I don't think this is the only reasonable option, but we need to move forward somehow.

Agreed.  However Jacob has been out on vacation for the past few days, I'd like to try a little more next week to see if we can come to some sort of compromise that he and Olli are OK with.  So at this point we're definitely not shipping passive in M50, and there's still a chance we may want to change the API before shipping in M51.  Given that, do you agree that leaving M49 as-is is still the best choice?  We're nearly out of time to change anything in 49 here.

I honestly wouldn't have expected such high usage, and if there's anything that could be done to learn something about it before the experiment reaches stable, that would be valuable. It could be a disaster, or it could all be due to a single site that actually works just the same with the inversion of capturing behavior. Would it make sense to let a custom build crawl the top million sites, does that infrastructure exist?

The closest thing we have at the moment is cluster telemetry, which loads the top 10k sites and captures some perf metrics.  It would take some work to wire that up to UseCounters, but may not be that bad.  I've started a thread on this and cc'd you, I agree it would be valuable. But I almost certainly won't be able to build this infrastructure in time for M49 stable.

If there's nothing that can be learned before stable, then leaving EventListenersOptions in M49 is the only remaining way to test whether objects as the third argument in existing web content is a deal-breaker. If we don't learn that, in the worst case months could be lost somewhere down the line, so I'd lean towards keeping it in and being very quick to revert if necessary.

Yep, I think that needs to be the plan.  Given that we haven't heard of any issue in beta I think the impact is very unlikely to be "a disaster".  The change is safe enough that, worst case, there's a non-trivial breakage, I suspect we could get the feature disabled on the stable branch (assuming we push a stable update for some other reason).

Philip

[Rick Byers]

We appear to have reached an impasse in the forwards compatibility debate - basically agreeing that there's no design which satisfies both camps, and that there's no more data to bring that could convince one side of the other's opinion.  In particular, Mozilla and Edge folks feel strongly that it's better to sacrifice some developer ergonomics in order to lower the forwards compatibility risk, while Google, Opera and Apple folks feel the compat risk is low enough that better developer ergonomics should win out.

I'm personally content with either choice, but we can't afford to delay shipping by another milestone. It's clear that the majority opinion of the DOM spec community is that the risk is not high enough to justify this change to the spec.  Since this feature is high-value and urgent, and there does not seem to be any path by which the DOM spec would change for this issue, and blink only ships APIs according to the specifications, I propose that we continue with our plans to ship with the spec'd API in M51.

Chris, since you gave your LGTM before this concern was raised, I consider it stale.  Can you please re-evaluate?  Any other API owners want to weigh in again?

If there's any bright side here it's that, if we proceed as planned, we're going to learn something new about the forwards compatibility risk of changing popular APIs in the platform which should help inform future such debates.  Also the main lesson for me is that I should have brought the incubation for this design to the WICG early on to ensure there were no barriers to having early design discussion openly including Microsoft (even though the eventual spec would still be a WHATWG one).  That's now been rectified, but I'll be sure to do that from the start for potentially contentious designs in the future.

I'd love to hear feedback anyone has on how best to handle such disagreements in the future (but please fork this thread or reach out elsewhere to avoid polluting the intent discussion that is primary here).

Thanks,

  Rick

[Chris Harrelson]

LGTM

Thank you for such thorough consideration of points of view and design alternatives.

I agree that your decision makes sense.

Chris

On Thu, Mar 17, 2016 at 9:46 AM Rick Byers <rby...@chromium.org> wrote:

We appear to have reached an impasse in the forwards compatibility debate - basically agreeing that there's no design which satisfies both camps, and that there's no more data to bring that could convince one side of the other's opinion.  In particular, Mozilla and Edge folks feel strongly that it's better to sacrifice some developer ergonomics in order to lower the forwards compatibility risk, while Google, Opera and Apple folks feel the compat risk is low enough that better developer ergonomics should win out.

I'm personally content with either choice, but we can't afford to delay shipping by another milestone. It's clear that the majority opinion of the DOM spec community is that the risk is not high enough to justify this change to the spec.  Since this feature is high-value and urgent, and there does not seem to be any path by which the DOM spec would change for this issue, and blink only ships APIs according to the specifications, I propose that we continue with our plans to ship with the spec'd API in M51.

Chris, since you gave your LGTM before this concern was raised, I consider it stale.  Can you please re-evaluate?  Any other API owners want to weigh in again?

If there's any bright side here it's that, if we proceed as planned, we're going to learn something new about the forwards compatibility risk of changing popular APIs in the platform which should help inform future such debates.  Also the main lesson for me is that I should have brought the incubation for this design to the WICG early on to ensure there were no barriers to having early design discussion openly including Microsoft (even though the eventual spec would still be a WHATWG one).  That's now been rectified, but I'll be sure to do that from the start for potentially contentious designs in the future.

I'd love to hear feedback anyone has on how best to handle such disagreements in the future (but please fork this thread or reach out elsewhere to avoid polluting the intent discussion that is primary here).

Thanks,

  Rick

On Mon, Feb 29, 2016 at 5:14 PM, Rick Byers <rby...@chromium.org> wrote:

On Sat, Feb 27, 2016 at 1:51 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Sat, Feb 27, 2016 at 2:14 AM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Feb 26, 2016 at 12:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Fri, Feb 26, 2016 at 4:22 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Feb 25, 2016 at 3:44 PM, PhistucK <phis...@gmail.com> wrote:

> So I believe we should go with option A for now

You mean that you believe that we should go with option B, right?

D'oh, yes - thanks. 

Can a (100%? 80%?) field trial (on Chrome 49) be of assistance for testing the water? If so, consider this option E?

It's not a crazy idea, but I don't think it's appropriate here.  We've generally avoided enabling web-exposed APIs via a field trial because it makes it a lot harder for developers to reason about behavior / regressions.  Instead we rely on the staging of chromium's shipping process to manage the risk.  Given that this particular feature has gotten all the way through beta without a single report of an issue, I think the compat risk is relatively low compared to other features.

 

What worries me, is that the usage seems to already be rising even before this is shipped to stable, like (I think) Phillip pointed out at some point.

Yeah that worries me too.  But note that the trend is all in M48 before we had the feature, so whoever is newly passing objects to addEventListener is mostly doing so in browsers that coerce that to 'true'.  It's possible (even likely?) that's a bug in some popular site / library that is completely unrelated to EventListenerOptions.

It's not necessarily a bug, it could be some code that wants capturing behavior and just happens to be using an object as the truthy value. If it's really just on M48 that would be hard to explain by something in the wild, though, an internal page seems more likely. How high is usage on M48? Is it the same for all platforms? Any weekend variability?

Looking at this again, we were confused - sorry!  This use counter was added in M48 which went stable around Jan 26 and didn't really get close to peak volume until around Feb 4.  This bump we see in the graph is only because prior to Jan 26 we were looking at a metric only reported by beta channel while still using the total page loads from all channels in the denominator.   The actual value has been holding quite steady over time and across milestones at around 0.02%-0.03% of page loads.  Sorry for the confusion!

[For the pedantic, yes this graph is showing the proportion of FeatureObserver entries with the value in question, which isn't quite the same thing as the proportion of page loads with a particular value.  We divide by the 'PageDestruction' bucket count to get the proportion of page loads, but I verified that PageDestruction holds steady (across this time and milestones) around 4% of all FeatureObserver entries.  So although the absolute value is wrong (not that you can tell from the unhelpful y-axis scale), the representation of the relative change over time as a function of page loads is still valid].

So disclaimer aside, the value is 0.02%-0.03% if normalized in the same as the chromestatus.com is? That's actually a fairly big number. It's a safe bet that very few happen to be {capture:true}, so pretty much all of these will be a change in behavior from capturing to non-capturing.