[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 #94 from Dimitri Glazkov <dglazkov@chromium.org> ---
(In reply to Olli Pettay from comment #82)
> The setup the spec has oddly prioritizes top most shadow trees over the
> nested ones.
> Using https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887#c62 as an example.
> if p1.onclick = function(e) { e.stopPropagation(); }, then nothing
> in the shadow tree 2 will see the event during bubble phase.
> And since shadow tree 1 is there first also during capture phase, 
> p1.parentNode.addEventListener("click", function(e) { e.stopPropagation() },
> true); would also prevent shadow tree 2 to see the event.
> Why the shadow tree which has the final insertion has lower priority than
> the first shadow tree?

I tried to apply this thinking to both the spec'd and newly proposed event
paths and I am stuck. Please help.

Let's take example 2 from https://etherpad.mozilla.org/RKukNtHHlO.

Suppose that I am an author of sh1 and sh2 is actually some component that I
found on the internet. I have no idea how it works. The author of this
component, however, calls e.stopPropagation() in ip2. Let's say I don't know
this. That's what composition is about, right? :)

In spec'd event path, I see this the resulting event path as [x1, ip1]. Which
sort of makes sense -- I clicked on x1, and I should at least hear something
coming out of ip1, because _I know_ that x1 is distributed there.

In new proposal, I see [x1] only. That seems bad. Suddenly, even though x1 is
distributed into my ip1, some force of nature grabbed the emergency brake and
my event just disappeared.

Am I crazy? At least to me, the spec'd event path actually makes sense, whereas
the new proposal results in mysterious silence.

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

Received on Friday, 28 March 2014 23:39:50 UTC