This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is to address the issues here: http://www.whatwg.org/issues/#seamless-events Basically I'd like a way to be able to, from the HTML spec, set up event retargetting so that I don't have to monkeypatch the DOM event dispatch model, I just need to invoke some hooks and get the effect described in the e-mails above. No need for DOM Core to know about Window, <iframe>, or MouseEvents, just define a way to configure the dispatch tree, and a "spec callback" that is invoked when events are to be cloned, to set up the events' attributes and to determine if the events should be retargetted or something. Ideally this would be specced in such a way that it could also be used for Web components when the dispatching for those is defined.
I thought it was agreed that event retargeting won't work with seamless. However there were some comments about pre-calculating event target chain, if a new event would be dispatched to the outer document.
Since for seamless the trees can access each other synchronously, why not set the coordinates for mouse events and such relative to the outer document when dispatched within a seamless document and just extend the event tree (as is done already for Window).
Because the coordinates would be then wrong in the child document.
Why wouldn't retargeting work? So long as it's a separate object, it seems like it'd work fine.
Dispatching takes an optional "re-dispatching steps". After the capturing phase is completed, if those steps are given, those steps are run, and then it skips the target phase. So you dispatch on the parent document first with those re-dispatching steps, and those re-dispatching steps get passed the event object (or a copy if you wish) which you mutate and dispatch on your document. Does that work or did you envision something else?
(In reply to comment #4) > Why wouldn't retargeting work? So long as it's a separate object, it seems > like it'd work fine. If it is a separate object (which in case of mouse and touch etc events have coordinates related to event.defaultView) and not just re-targeting, the it should work.
I was hoping for something that would take care of more of it for me, but I'll have to see how this works. :-)
https://github.com/whatwg/dom/commit/22ce02cb28a5225355883c4d77a3f3b1f257d820 Basically, you determine if you want to dispatch in the parent instead. If you do, you dispatch it there with redispatching steps attached. The redispatching steps manipulate the copy of event as desired and then dispatch it. If rather than a parent you an ancestor the dispatching steps will need a slightly more complex definition. Exercise for the reader ;-)
1. https://github.com/whatwg/dom/commit/22ce02cb28a5225355883c4d77a3f3b1f257d820 2. http://krijnhoetmer.nl/irc-logs/whatwg/20121204#l-1344 (and around there) This is kinda super complex, so if implementors are not sure they're going to implement this, I'd like to know :-)
Revert 1. I meant.
See also: http://krijnhoetmer.nl/irc-logs/whatwg/20121205#l-4
HTML spec now references the "event cross-boundary parent" (for seamless iframes) and (in a comment currently) the "event parent" (for Window).
I thought I should explain that the reason this is taking ages is because Shadow DOM has requirements for modifying the dispatch chain as well that are slightly more involved than the requirements for <iframe>. Shadow DOM requires that when building the dispatch chain for each node in that dispatch chain we also cache a target and if the event being dispatched is a MouseEvent or FocusEvent, a relatedTarget. (For touch events it would be even more involved I think, but there's no implementation of that yet.) Given the way Shadow DOM creates this dispatch chain I don't see a clean way of providing hooks in the DOM that would make all this work neatly together. It seems the entire algorithm would have to be in the DOM, including the concept of shadow trees. Input welcome.
Relevant code to study: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventRetargeter.cpp http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventDispatcher.cpp
I am the author of these code, EventDispatcher.cpp and EventRetargter.cpp in WebKit. I am glad if I could help. (In reply to comment #14) > Relevant code to study: > > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventRetargeter.cpp > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/EventDispatcher.cpp
Ian, is seamless dead now Chrome killed it?
FWIW, we're not opposed to the feature. Finishing our implementation was just not at the top of our priorities at the moment and won't be anytime in the near future.
Seamless is not dead; see bug 24400.
Are we going to wait another year for implementations to emerge? (Fine by me btw.)
Resolving this since iframe[seamless] has in fact now been dropped from HTML: https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311