Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

Is it not possible for Javascript engines to statically determine if
preventDefault() is called by an event handler?

For example:

function myHandler(e)
{
    // does "e.preventDefault" occur anywhere in this body?
};

target.addEventListener("scroll", myHandler);

If none of the added event handlers reference the preventDefault property
of their first parameter, then the browser engine could optimise knowing
that preventDefault is never called. Then the developer does not need to
specify a flag, and no APIs need to be altered.

Since Javascript is dynamic it's not possible to tell exactly every time,
e.g. given the statement e[some_string_variable](), that could resolve to a
call to e["preventDefault"]() at runtime. This means really there are three
cases:

1. Yes: statically references e.preventDefault
2. Maybe: some dynamic reference like e[str]
3: No: no dynamic references, and no static references to e.preventDefault

Assuming the "maybe" case is rare, then it could be conservatively treated
as "yes". Then for most reasonable real-world cases, you have a way to
optimise scroll events without using any more information from the
developer.

A simple way to determine the "no" case could be to identify handlers with
no parameters at all, e.g:

function myHandler() // no parameter
{
    // ...
};

...certainly cannot access e.preventDefault(), because it does not use the
event in its parameters. (The function also should not reference
"arguments" at all.) I don't know if libraries typically need the event for
any other purposes, but this seems like at least one straightforward way
for the developer to indicate "I won't call preventDefault()" without any
new API.

Ashley



On 8 July 2015 at 20:12, Rick Byers <rbyers@chromium.org> wrote:

> [Cross-posted to www-dom@w3.org - please let me know if there's a better
> way to account for the DOM spec duality]
>
> In Chromium we've long worked hard at maximizing  scroll performance, with
> scroll-blocking DOM events (wheel and touchstart in particular) being by
> far the biggest source of scroll jank.
>
> I've been talking about this problem off-and-on for several years with
> various folks including the Pointer Events Working Group, engineers of
> other browser vendors, and engineers working on popular libraries that are
> a source of such scroll-blocking event handlers (eg. Google Ads and
> Google Analytics).
>
> I've now written a relatively formal (but still sloppy by W3C standards)
> concrete spec for extending the DOM event model
> <http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html>
> to
> address this problem and would like to solicit feedback.  It's probably
> most constructive to discuss specific issues on GitHub
> <https://github.com/RByers/EventListenerOptions/issues>, but I'd
> appreciate
> any high-level feedback here by e-mail too.  Please feel free to submit
> pull requests for eg. editorial improvements.
>
> Once there's a bit more consensus on the API shape, I plan to write a
> polyfill and tests and then begin a prototype implementation in Chromium.
> We have some initial evidence to believe that this (in partnership with a
> few key library authors) can make a substantial improvement to the user
> experience on mobile.  I hope to be able to share more concrete data on the
> real-world performance impact, but there's obviously a chicken and egg
> problem here.
>
> Thanks,
>    Rick
>

Received on Sunday, 12 July 2015 16:47:45 UTC