[Bug 23887] [Shadow] Put only the final destination insertion point to the event path

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887

Jonas Sicking <jonas@sicking.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jonas@sicking.cc

--- Comment #57 from Jonas Sicking <jonas@sicking.cc> ---
First off, I think we should look at this from the point of view of use cases.

What is the use case for adding an event listener to an insertion point? A user
can't ever click an insertion point because they are not rendered.

However it does seem nice and intuitive if an event listener attached to an
insertion point ends up receiving events targetted at any of the nodes inserted
into that insertion point. As well as those nodes descendants of course.

And for the sake of consistency, this should always happen, no matter if there
is shadow DOM attached to the parent of the insertion point or not. And no
matter if there is shadow DOM attached to one of the nodes inserted into that
insertion point.

Assuming that we can do this without creating large performance problems, and
without creating too weird edge cases, do people agree that this is a laudable
goal?


So I read comment 50 and also ended up with the same question as bz. Why not
the more intuitive propagation path of 3,2,10,9,8,7,6,5,4,1?


So I started writing a comment why Dimitri's logic in comment 52 didn't make
sense.

And instead writing the logic that would lead to bz's intuitive propagation
path in comment 50 (3,2,10,9,8,7,6,5,4,1).

However I realized that I couldn't come up with a logical set of rules that
would lead to that path.

While it seems to make sense to have that <shadowroot id="8"> come before the
<content id="7">, I couldn't motivate why that should be.

And, more importantly, it only seems to make sense if the '7' insertion point
is an immediate child of the '6' shadow host. Let's insert an <a> element
between the '6' and the '7' nodes, such that we get the following tree:

  <shadowroot id="4">
    <div id="5">
      <div id="6">
        <a>
          <content id="7"></content>
        <a>
      </div>
    </div>
  </shadowroot>


In this case no node is inserted into multiple insertion points, which makes
the whole thing much simpler. The '2' node is inserted into the '7' insertion
point, and the 'a' node is inserted into the '10' insertion point.

In this case it's pretty clear that an event fired at the '3' node would get a
propagation path of 3,2,7,a,10,9,8,6,5,4,1

So it makes sense to me that if you simply remove the 'a' and insert the '7'
directly into the '6', that you'd get the same propagation path but with the
'a' removed. I.e. 3,2,7,a,10,9,8,6,5,4,1


I've read through the initial comments in this bug but I don't see the
inconsistencies that are being discussed there. I.e. all of the following
appears true:

* No node ever receives the same event twice.
* Any time an event reaches a node, it also reaches the node's parent.
* During the capturing phase, a node always receives an event before its
children.
* During the bubbling phase, a node always receives an event after its
children.
* The only way to receive an event multiple times in the same shadow tree is by
  registering listeners on multiple nodes, where some of the nodes are
ancestors of
  other nodes.

All of the above appears to be true both both with and without the shadow DOM
spec.

The only way that I can see that you could receive the same event multiple
times is if you register event listeners in multiple different shadow trees. In
that case it doesn't seem surprising that you can receive an event multiple
times. It's something that happens even in the very simple event model that
XBL1 uses.

Is the above wrong? Or is there some other inconsistency that I'm missing? Or
is the concern about performance at this point?

Examples would be very helpful.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 22 March 2014 04:17:54 UTC