18780 2012-09-05 18:07:45 +0000 Fix event dispatching for shadow DOM and <iframe seamless> 2016-01-23 05:18:50 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC All RESOLVED WONTFIX P2 normal --- 21066 16487 1 ian annevk bugs dglazkov erik.arvidsson hayato ian jonas mike ojan www-dom public-webapps-bugzilla oldest_to_newest 73243 0 ian 2012-09-05 18:07:45 +0000 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. 73247 1 bugs 2012-09-05 18:19:26 +0000 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. 73282 2 annevk 2012-09-06 08:18:01 +0000 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). 73285 3 bugs 2012-09-06 09:01:34 +0000 Because the coordinates would be then wrong in the child document. 78616 4 ian 2012-11-21 23:56:02 +0000 Why wouldn't retargeting work? So long as it's a separate object, it seems like it'd work fine. 78641 5 annevk 2012-11-22 09:44:14 +0000 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? 78648 6 bugs 2012-11-22 12:14:28 +0000 (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. 78660 7 ian 2012-11-22 19:23:21 +0000 I was hoping for something that would take care of more of it for me, but I'll have to see how this works. :-) 78701 8 annevk 2012-11-23 14:23:24 +0000 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 ;-) 79433 9 annevk 2012-12-04 20:56:32 +0000 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 :-) 79434 10 annevk 2012-12-04 20:57:15 +0000 Revert 1. I meant. 79441 11 ian 2012-12-04 23:08:55 +0000 See also: http://krijnhoetmer.nl/irc-logs/whatwg/20121205#l-4 79446 12 ian 2012-12-04 23:59:20 +0000 HTML spec now references the "event cross-boundary parent" (for seamless iframes) and (in a comment currently) the "event parent" (for Window). 83385 13 annevk 2013-02-20 11:53:49 +0000 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. 83386 14 annevk 2013-02-20 11:55:40 +0000 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 83389 15 hayato 2013-02-20 13:18:17 +0000 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 100429 16 annevk 2014-02-12 19:50:20 +0000 Ian, is seamless dead now Chrome killed it? 100436 17 ojan 2014-02-12 20:44:42 +0000 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. 102209 18 ian 2014-03-11 16:58:55 +0000 Seamless is not dead; see bug 24400. 120233 19 annevk 2015-05-08 09:20:49 +0000 Are we going to wait another year for implementations to emerge? (Fine by me btw.) 124679 20 mike 2016-01-23 05:18:50 +0000 Resolving this since iframe[seamless] has in fact now been dropped from HTML: https://github.com/whatwg/html/commit/1490eba4dba5ab476f0981443a86c01acae01311