Re: [whatwg/dom] event.composedPath() may return different results if DOM is modified between two calls (#525)

> How is that O(depth)?

I'd assumed "Just annotate each event path tuple in a subtree" requires iterating over each node in the path, and thus computing the path, which is O(depth).

> We have to spend O(depth) cost at any case in event dispatching.

I don't think we do. We can easily tell when there is no capture event listener for a given event name in the document beforehand, just by keeping track. Which means that for non-bubbling events of that type we can just totally avoid event path computation and only dispatch on the single node.

>From what I understand talking to @ikilpatrick Blink does not currently implement this optimization because of Blink's non-standard `event.path` which is computed eagerly. But we could implement it, and thus have O(1) event dispatching in the somewhat-common case I am talking about. We should not prevent ourselves or other browsers from achieving this speed-up, if at all possible.

If it would be helpful I can implement this O(1) dispatching in [jsdom](https://github.com/tmpvar/jsdom) so you can see an example of how the implementation would look.

> Blink has some optimization for some kind of events so that we can skip event path calculation entirely. But this case is limited.

Maybe the case is currently limited in Blink, but I think it could be quite common. (All non-bubbling events when there are no composed listeners for that event type on the document.) Regardless of how limited or common it is, it would be sad to mandate in the spec that we can *never* skip the event path calculation.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/525#issuecomment-340701533