Bug 18780 - Fix event dispatching for shadow DOM and <iframe seamless>
Summary: Fix event dispatching for shadow DOM and <iframe seamless>
Status: REOPENED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on: 21066
Blocks: 16487
  Show dependency treegraph
 
Reported: 2012-09-05 18:07 UTC by Ian 'Hixie' Hickson
Modified: 2015-05-08 09:20 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2012-09-05 18:07:45 UTC
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.
Comment 1 Olli Pettay 2012-09-05 18:19:26 UTC
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.
Comment 2 Anne 2012-09-06 08:18:01 UTC
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).
Comment 3 Olli Pettay 2012-09-06 09:01:34 UTC
Because the coordinates would be then wrong in the child document.
Comment 4 Ian 'Hixie' Hickson 2012-11-21 23:56:02 UTC
Why wouldn't retargeting work? So long as it's a separate object, it seems like it'd work fine.
Comment 5 Anne 2012-11-22 09:44:14 UTC
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?
Comment 6 Olli Pettay 2012-11-22 12:14:28 UTC
(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.
Comment 7 Ian 'Hixie' Hickson 2012-11-22 19:23:21 UTC
I was hoping for something that would take care of more of it for me, but I'll have to see how this works. :-)
Comment 8 Anne 2012-11-23 14:23:24 UTC
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 ;-)
Comment 9 Anne 2012-12-04 20:56:32 UTC
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 :-)
Comment 10 Anne 2012-12-04 20:57:15 UTC
Revert 1. I meant.
Comment 11 Ian 'Hixie' Hickson 2012-12-04 23:08:55 UTC
See also: http://krijnhoetmer.nl/irc-logs/whatwg/20121205#l-4
Comment 12 Ian 'Hixie' Hickson 2012-12-04 23:59:20 UTC
HTML spec now references the "event cross-boundary parent" (for seamless iframes) and (in a comment currently) the "event parent" (for Window).
Comment 13 Anne 2013-02-20 11:53:49 UTC
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.
Comment 15 Hayato Ito 2013-02-20 13:18:17 UTC
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
Comment 16 Anne 2014-02-12 19:50:20 UTC
Ian, is seamless dead now Chrome killed it?
Comment 17 Ojan Vafai 2014-02-12 20:44:42 UTC
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.
Comment 18 Ian 'Hixie' Hickson 2014-03-11 16:58:55 UTC
Seamless is not dead; see bug 24400.
Comment 19 Anne 2015-05-08 09:20:49 UTC
Are we going to wait another year for implementations to emerge? (Fine by me btw.)