Re: [IndexedDB] Redesign propagation path (#66)

hmm, well, conceptually an event target doesn't define the whole path. An event target just knows about itself and the next item in the path. Usually node and the edge 'node->parentNode'.
IDB works the same way, since there is just one implementation to dispatch DOM events in Gecko at least. IDB dispatches event to target Foo, and among the first steps of dispatch event target chain (that happens to be what Gecko calls the propagation path) is created using a_target_in_chain -> next_target edges [1].
This setup lets event target to also filter out events. For example Document can return null as the next item in the chain when 'load' event is being dispatched somewhere in the DOM tree (since load is special). [2]

So it might be easiest to spec it so that each EventTarget has conceptual parent target.
By default null (for XHR, WebSocket etc), but Nodes would have parentNode, except in case of ShadowDOM, and some IDB objects would also have special parent.


[1] http://mxr.mozilla.org/mozilla-central/source/dom/indexedDB/IDBRequest.cpp?rev=e22b3043887e&mark=457-457#452
[2] http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp?rev=6ecb187ce925&mark=8078-8083#8071

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/66#issuecomment-185231946