- From: <bugzilla@jessica.w3.org>
- Date: Fri, 28 Mar 2014 23:39:49 +0000
- To: public-webapps-bugzilla@w3.org
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