Intent to Implement: add EventListenerOptions.passive

[Dave Tapuska]

Contact emails dtap...@chromium.org,rby...@chromium.org Spec https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive] 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. Motivation Exposing this boolean will allow threaded rendering to possibly start scrolling without waiting for the main thread to execute the registered event listener since the event is just passive and won't preventDefault the action.

Interoperability and Compatibility Risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive

Engaged web developers are excited by the cases of improving their scrolling performance while maintaining some of the data mining behaviour they are using their registered event listeners.

Describe the degree of compatibility risk you believe this change poses Low compatibility risk.

Ongoing technical constraints

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

Yes OWP launch tracking bug http://crbug.com/489802 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5745543795965952 Requesting approval to ship?

No

[Rick Byers]

On Fri, Jan 8, 2016 at 10:39 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails dtap...@chromium.org,rby...@chromium.org Spec https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive] 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. Motivation Exposing this boolean will allow threaded rendering to possibly start scrolling without waiting for the main thread to execute the registered event listener since the event is just passive and won't preventDefault the action.

Do you want to ship support for the 'passive' option ahead of implementing some actual perf optimization (which is really the hard part here)?  Or would we hold off and ship both at the same time?   I see arguments to both choices, not sure myself which is best (but we should probably agree one way or another as part of this intent).  Getting the full performance benefit possible from this option is hard in our current architecture, so I definitely wouldn't want to block shipping the option on doing everything possible.

Interoperability and Compatibility Risk Firefox: No public signals

 Olli from Mozilla (cc'd) was heavily involved in the design (IIRC the basic idea of an option which signaled that listeners didn't intend to cancel the event was his).  But this issue has a long and complex history (some in the links here).  So I'll leave it to Olli to say whether or not he thinks where we  ultimately landed is something supports adding to the web platform.

Edge: No public signals

/cc Jacob Rossi in case he wants to go on the record with any feedback (we've discussed it privately extensively).

Safari: No public signals

Note that Simon Fraser has shown some support by filing a WebKit bug.  But that in itself isn't necessarily a strong public signal.

Web developers: Positive

Engaged web developers are excited by the cases of improving their scrolling performance while maintaining some of the data mining behaviour they are using their registered event listeners.

Describe the degree of compatibility risk you believe this change poses Low compatibility risk.

Note that current versions of the template (where did you get this one?) ask for "compatibility and interoperability risk".  Without public support from other vendors, there's definitely interoperability risk :-).

Ongoing technical constraints

None

 

The difficult technical problem here are all around implementing the perf optimization possible.  Technically I think there's some risk that we'd ship that, and sites will come to depend on it further (such that scrolling on many websites can't be done smoothly without supporting this feature and underlying perf optimizations).  Then we'd probably be locked into the resulting complex optimizations (eg. ability to hit-test for touch handlers and ultimately touch-action from the compositor thread).  This is similar to the bigger picture issue of being locked into support threaded scrolling forever.  I personally believe this is the right trade off, but it's certainly highly controversial.

[Rick Byers]

On Mon, Jan 11, 2016 at 12:08 PM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Jan 8, 2016 at 10:39 PM, Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails dtap...@chromium.org,rby...@chromium.org Spec https://dom.spec.whatwg.org/#dom-eventlisteneroptions-passive] 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. Motivation Exposing this boolean will allow threaded rendering to possibly start scrolling without waiting for the main thread to execute the registered event listener since the event is just passive and won't preventDefault the action.

Do you want to ship support for the 'passive' option ahead of implementing some actual perf optimization (which is really the hard part here)?  Or would we hold off and ship both at the same time?   I see arguments to both choices, not sure myself which is best (but we should probably agree one way or another as part of this intent).  Getting the full performance benefit possible from this option is hard in our current architecture, so I definitely wouldn't want to block shipping the option on doing everything possible.

Interoperability and Compatibility Risk Firefox: No public signals

 Olli from Mozilla (cc'd) was heavily involved in the design (IIRC the basic idea of an option which signaled that listeners didn't intend to cancel the event was his).  But this issue has a long and complex history (some in the links here).  So I'll leave it to Olli to say whether or not he thinks where we  ultimately landed is something supports adding to the web platform.

Edge: No public signals

/cc Jacob Rossi in case he wants to go on the record with any feedback (we've discussed it privately extensively).

Safari: No public signals

Note that Simon Fraser has shown some support by filing a WebKit bug.  But that in itself isn't necessarily a strong public signal.

Web developers: Positive

Engaged web developers are excited by the cases of improving their scrolling performance while maintaining some of the data mining behaviour they are using their registered event listeners.

Describe the degree of compatibility risk you believe this change poses Low compatibility risk.

Note that current versions of the template (where did you get this one?) ask for "compatibility and interoperability risk".  Without public support from other vendors, there's definitely interoperability risk :-).

Sorry, my mistake (was confused with the above).  I've submitted a PR to improve the dashboard template.

[ben.m...@gmail.com]

The difficult technical problem here are all around implementing the perf optimization possible.  Technically I think there's some risk that we'd ship that, and sites will come to depend on it further (such that scrolling on many websites can't be done smoothly without supporting this feature and underlying perf optimizations).  Then we'd probably be locked into the resulting complex optimizations (eg. ability to hit-test for touch handlers and ultimately touch-action from the compositor thread).  This is similar to the bigger picture issue of being locked into support threaded scrolling forever.  I personally believe this is the right trade off, but it's certainly highly controversial.

Wouldn't older browsers (eg, Internet Explorer, older versions of safari on iOS) provide some protection against sites becoming truly dependant on this feature?

Also, if somebody uses this optimization it wouldn't allow them to jank up the main thread for 100s of milliseconds without impacting the user. Ultimately any time spent in this event handler would block other types of events (such as a click handler) hurting the interactivity of the page. My sense is that if this optimization were provided then removed (due to a better method for doing these types of queries) sites that had implemented the old optimization might not render in an ideal way but would hardly be unusable. Performance best practices change over time, especially around advanced platform functionality. I don't think a developer should expect a deeply optimized program for the practices of 2016 to still be deeply optimized in 2017.

-b

[Dave Tapuska]

I do not request shipping this at the time. I anticipate that we would hold off shipment of this API change until we have some underlying code that actually benefits the user when they use passive event listeners. Then at least they can have some type of assurance calling it in some fashion gives some benefit. 

It should be noted that even if an app registers passive listeners and another part of code registers blocking listeners the whole thing degrades to effectively blocking style. So app writers should be aware this is a hint at an optimization possible; not a direct flag to give me threaded scrolling optimizations.

dave.

On Mon, Jan 11, 2016 at 12:08 PM, Rick Byers <rby...@chromium.org> wrote:

--
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.

[Rick Byers]

Thanks Ben, I agree with all that.  I personally believe the risk is pretty low here, but I wanted to still call this out as a risk (especially since I know many blink engineers have some regret around the ongoing burden of supporting threaded scrolling).

[Kenji Baheux]

+1 to holding on any shipping intent until there are actual benefits: I imagine that the communication around this feature will draw attention to it and it would be sad if developers were not able to observe any benefits while experimenting.

"It should be noted that even if an app registers passive listeners and another part of code registers blocking listeners the whole thing degrades to effectively blocking style."

I'm worried about this aspect.

• RAIL wise, would this effectively be a status quo as long as one player (e.g. the first party with valid reasons) uses blocking listeners*?
• For use cases that neither need to interfere nor be notified in realtime, is there a better alternative that doesn't necessitate a 100% opt-in? I've heard discussions about an async batching of events which seems to fit the bill. Any thoughts on the need to pursue both approaches?

Best,

[Rick Byers]

On Mon, Jan 11, 2016 at 9:55 PM, Kenji Baheux <kenji...@chromium.org> wrote:

+1 to holding on any shipping intent until there are actual benefits: I imagine that the communication around this feature will draw attention to it and it would be sad if developers were not able to observe any benefits while experimenting.

Yep, sounds like we all agree on this.  We _could_ ship the API sooner, but it's better to wait until some substantial benefit is observable. 

"It should be noted that even if an app registers passive listeners and another part of code registers blocking listeners the whole thing degrades to effectively blocking style."

I'm worried about this aspect.

• RAIL wise, would this effectively be a status quo as long as one player (e.g. the first party with valid reasons) uses blocking listeners*?
• For use cases that neither need to interfere nor be notified in realtime, is there a better alternative that doesn't necessitate a 100% opt-in? I've heard discussions about an async batching of events which seems to fit the bill. Any thoughts on the need to pursue both approaches?

Assuming we're talking about the common case of listeners on the document/body, this "all listeners must update to enable the optimization" property is inherent in the design of wheel/touch events.  Any listener may prevent the scroll, so we can't scroll until we know that NONE will.  Any fully web compatible solution to the problem will have this property.

However, as I've surveyed sites I've anecdotally found examples where fixing one popular library is all that's necessary to get a dramatic benefit.  Eg. try remote debugging this scientific american page and remove the single touch handler installed by parse.ly, it's night-and-day better when doing scrolling that shows or hides the top controls (though there's probably also some layout bug here making layout so expensive).

That said, I agree this won't be enough to fully solve the problem.  Once we have good tools / guidance for web developers, I intend to push on an intervention to effectively automatically opt some slow sites into passive listeners (replacing our current "touch ACK timeout" hack).  I' expect to send the start of a concrete proposal for this to interventions-dev@ shortly in the next week or so (though this is a long-term effort - don't expect to ship an intervention in Q1).