W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

[Bug 26892] New: [Shadow]: Consider not using AT_TARGET more than once in the event path

From: <bugzilla@jessica.w3.org>
Date: Tue, 23 Sep 2014 15:36:32 +0000
To: public-webapps@w3.org
Message-ID: <bug-26892-2927@http.www.w3.org/Bugs/Public/>

            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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC