- From: Rick Byers <rbyers@chromium.org>
- Date: Sat, 11 Jul 2015 17:41:53 -0400
- 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 top-posting] 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). Rick 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