[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

--- Comment #64 from Jonas Sicking <jonas@sicking.cc> ---
Ah, I think I see the issue indeed.

In Olli's example the "tree" that the DOM events code sees is this (I took the
liberty of adding id's to the shadowroots for clarity):

<div id="sh1">
  <shadowroot id='sr1'>
    <span id='sh2'>
      <shadowroot id='sr2'>
        <content id='ip2.1' select='#s1'>
          <content id='ip1'>
            <span id="s1"> [click me 1] </span>
          </content>
        </content>
        <content id='ip2.2' select='#s2'>
          <content id='ip1'>
            <span id="s2"> [click me 2] </span>
          </content>
        </content>
      </shadowroot>
    </span>
  </shadowroot>
</div>

Note that the <content id='ip1'> node shows up twice!

I.e. if you fire an event on s1 the event path is
s1,ip1,ip2.1,sr2,sh2,sr1,sh1

And if you fire an event on s2 the event path is
s2,ip1,ip2.2,sr2,sh1,sr1,sh1

I.e. in both cases does the event go through ip1 (which is expected given that
both s1 and s2 are inserted into ip1), but ip1's parent is different in the two
events.

I'm curious, what does the spec say the event path is if you target an event on
the ip1 node? Or on insertion points in general?


I still don't feel convinced either way of what the right thing to do here is.

I don't think including just the innermost insertion point is a good solution
since it introduces other types of inconsistencies. I.e. it would mean that
adding a shadow DOM to sh1 means that suddenly ip1 doesn't see any events. This
will prevent any type of encapsulation.

And preventing any and all events to go through insertion points seems like
breaking a useful feature.

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

Received on Saturday, 22 March 2014 17:45:06 UTC