- From: <bugzilla@jessica.w3.org>
- Date: Thu, 12 Feb 2015 12:48:57 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23887 --- Comment #143 from Olli Pettay <bugs@pettay.fi> --- (In reply to Koji Ishii from comment #141) > With so much thanks to Olli, wchen, and Hayato, I've experimentally > implemented the proposed algorithm, and now I'm seeing two different results > in our tests. > > The two are minor, but since they are changes in the behavior not discussed > in this thread yet, any opinions/insights from anyone is also appreciated. > > 1. The proposed algorithm stops event path for orphaned nodes > When target nodes are not distributed, the event path in the current spec > bubbles up to Document, but the proposed algorithm stops. Example: > > A > SR > B > > Note that SR does not have IP. When an event fires on B, the event path is: > Current: B, SR, A, Document, Window > Proposed: B But shouldn't B's destination insertion points be empty and from B event propagate to A. Or do I misunderstand your example? (B is a child node of A) > > This also occurs when younger shadow roots do not have any shadow insertion > points. In which case exactly? If you dispatch event to a node in older shadow tree and younger doesn't have insertion point, event should propagate only to the older shadow root. > 2. Events that are Always Stopped at...where? > The current spec of "Events that are Always Stopped" says "...stopped at the > root node of the node tree" > http://w3c.github.io/webcomponents/spec/shadow/#h-events-that-are-always- > stopped > > Current our implementation allows older and younger shadow roots to receive > the event and stops before shadow hosts. hosts? plural? mousemove _within_ older shadow dom shouldn't propagate to the younger shadow dom -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 12 February 2015 12:49:00 UTC