W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

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

From: Rick Byers <rbyers@chromium.org>
Date: Sat, 11 Jul 2015 17:41:53 -0400
Message-ID: <CAFUtAY-SnTtmxnUph6_sLmib1sW+B3hCsSBKpY=tu8nYvisPSg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Jonas Sicking <jonas@sicking.cc>, WHATWG <whatwg@whatwg.org>, "olli@pettay.fi" <olli@pettay.fi>, Domenic Denicola <d@domenic.me>, Dave Tapuska <dtapuska@chromium.org>, Tim Dresser <tdresser@chromium.org>
[On vacation now with only a phone - so apologies for the brevity and

What Anne describes is perfect!  I'm not hung up on the value of cancelable
itself - some internal bit on Event that makes preventDefault a no-op (or
event throw) during listener invocation is fine with me (and I agree - less
weird).  If code really wants to test whether it's call to preventDefault
took effect, it can check defaultPrevented afterward.

I'm also not worried about the setTimeout example.  Calls to preventDefault
after dispatch is done have no effect, so at best such code was already
unpredictable (probably always a no-op already).

On Jul 11, 2015 3:14 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote:

> On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola <d@domenic.me> wrote:
> > I'm not sure that actually matters though, since canceling inside
> setTimeout(,0) shouldn't have much affect besides changing
> `e.defaultPrevented`. So maybe it's OK.
> It's fine. The code that dispatches an event and then checks the
> event's canceled flag will run before a task queued by invoking
> setTimeout() during dispatching runs. You can only change course if
> you change the canceled flag during dispatch (which this new way of
> listening would prevent).
> --
> https://annevankesteren.nl/
Received on Saturday, 11 July 2015 21:42:20 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 11 July 2015 21:42:20 UTC