- From: <bugzilla@jessica.w3.org>
- Date: Tue, 23 Sep 2014 15:36:32 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26892 Bug ID: 26892 Summary: [Shadow]: Consider not using AT_TARGET more than once in the event path Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglazkov@chromium.org Reporter: dglazkov@chromium.org QA Contact: public-webapps-bugzilla@w3.org CC: mike@w3.org, public-webapps@w3.org Blocks: 14978 I was wrong in bug 15543. The effect of invoking event listeners with AT_TARGET at each shadow host along the event path is that even non-bubbling events appear to bubble. This is especially evident in situations where logical units of an application are composed using Shadow DOM. Here's a simple example: I am building a grocery list app. Suppose I am currently making the grocery list editor. The EDIT ITEM dialog box is in its own shadow tree. Inside of this box, I have input fields, as well as a CANCEL button and a DELETE button. Clicking CANCEL fires a simple 'cancel' event on the EDIT ITEM's shadow host. The event is meant to be listened to by the owner of the EDIT ITEM dialog box (to close it, presumably). Clicking DELETE opens another CONFIRM DELETE dialog (also in a shadow tree) on top of the EDIT ITEM dialog. That dialog has OK and CANCEL as well. Suppose that I repeat my event pattern on the CONFIRM DELETE dialog. Clicking CANCEL there fires a simple 'cancel' event. The idea is that my EDIT ITEM dialog can listen to this event and close the CONFIRM DELETE dialog. Sounds simplistic enough, right? Here's where things get interesting. Unfortunately for me, when I click on CANCEL in the CONFIRM DELETE dialog, my EDIT ITEM dialog goes away as well! The reason for this strange occurrence is because, despite 'cancel' being a simple event, the AT_TARGET listener invocation occurs both at the CONFIRM DELETE shadow host and at the EDIT ITEM shadow host. In other words, the bubbling event listener that is only supposed to hear EDIT ITEM's 'cancel' event will also hear the CONFIRM DELETE's 'cancel' event -- even though I, the developer, specifically told this event not to bubble. Now I have no choice but work around this problem by attempting to distinguish different 'cancel' events that are coming through. I think the solution to this conundrum is the same as the one for the bug 20247. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 23 September 2014 15:36:39 UTC