Mention that in:
https://github.com/w3c/webcomponents/commit/69fbceabe01786ba3740728a6b86f5ec958f69b4

Though we might need more further clarification, let me close this bug.

This doesn't seem like a good change. It means that event dispatch does totally different things in a detached subtree. What happens when you compose a bunch of polymer elements and they start dispatching events to talk to each other but aren't in the document yet?

(In reply to Elliott Sprehn from comment #2)
> This doesn't seem like a good change. It means that event dispatch does
> totally different things in a detached subtree. What happens when you
> compose a bunch of polymer elements and they start dispatching events to
> talk to each other but aren't in the document yet?

The sad news is that, as for WebKit and Blink, an event dispatching mechanism has been *broken* in disconnected nodes for years.

See https://code.google.com/p/chromium/issues/detail?id=249582

I tried to fix that, but it caused multiple crashes. The previous attempt has been reverted. That is still broken, I guess.

From that, I believe no one is using event dispatch to make something useful in disconnected nodes.

The relevant review in chromium side is: https://codereview.chromium.org/133213008/

Adding Scott to cc, because I'd like to know whether Polymer depends on event dispatching mechanism in disconnected nodes or not.

In the current implementation of blink (and WebKit), if an event happens on a disconnected node, it's event path will contain only one node, the node itself. Bubbling doesn't happen at all.
See
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/events/EventPath.cpp&q=EventPath&sq=package:chromium&l=149

>> I believe no one is using event dispatch to make something useful in disconnected nodes

This is accurate to my knowledge. In general, my expectation is that event dispatch doesn't work in disconnected subtrees.

I don't mean to say it wouldn't be a useful concept; I've never really thought about it. But at least for now, the status quo, AFAIK, is no expectation there.

Yeah, I assumed that Polymer doesn't depend on event dispatching in detached nodes.

However, there is still a possibility that Polymer uses distribution result through some APIs, such as getDistributedNodes(), even in detached nodes. In addition that, I've heard that Polyfill does composition even in detached nodes. That might not be intentional and might not be required, however, for the safety and consistency between Polyfill and native Shadow DOM, I've reverted the chromium side patch, https://codereview.chromium.org/133213008/.

As for the spec, let me leave the spec as is and close this bug.
It might be safer to make the behavior of detached nodes *undefined*.
If we can feel we should support distributions even in detached nodes, we can relax this restriction in the future without breaking incompatibility if we leave it *undefined*.

Please file a bug for 'Support distributions even for detached nodes' as another issue.

s/without breaking incompatibility/without breaking compatibility/.

(In reply to Hayato Ito from comment #4)
> In the current implementation of blink (and WebKit), if an event happens on
> a disconnected node, it's event path will contain only one node, the node
> itself. Bubbling doesn't happen at all.
> See
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/
> WebKit/Source/core/events/EventPath.cpp&q=EventPath&sq=package:chromium&l=149
Is that even for nodes not in shadow DOM? Sounds like a major bug.
Whether or not node is in document must not affect at all to the
event propagation.

(In reply to Olli Pettay from comment #8)
> (In reply to Hayato Ito from comment #4)
> > In the current implementation of blink (and WebKit), if an event happens on
> > a disconnected node, it's event path will contain only one node, the node
> > itself. Bubbling doesn't happen at all.
> > See
> > https://code.google.com/p/chromium/codesearch#chromium/src/third_party/
> > WebKit/Source/core/events/EventPath.cpp&q=EventPath&sq=package:chromium&l=149
> Is that even for nodes not in shadow DOM? Sounds like a major bug.
> Whether or not node is in document must not affect at all to the
> event propagation.

It is a major WebKit/Blink bug and once it is fixed it would be confusing if the event path is different whether disconnected or not.

To me it is obvious that things should work the same whether in document or not. Composition is not related to in document in any way and adding that restriction is a very arbitrary exception. One might as well say that "display: none" elements have no distribution, or that we do not distribute on the leap day.

> without breaking incompatibility if we leave it *undefined*.

That's not how compatibility works.  Compatibility issues are always with _behavior_, not with _specs_.

It sounds like you just need to fix the breakage in Blink/WebKit here.

> To me it is obvious that things should work the same whether in document or not.

I agree.

Reopening this bug; I don't think the current setup is at all acceptable.

I also agree with Erik and Boris on this.  WebKit/Blink bugs shouldn't prevent specification from defining a normative behavior.  In fact, we should have test cases that demonstrate WebKit/Blink bugs as needed.  If WebKit/Blink cannot be conformant due to the bug, then so be it.  That's no excuse for the specification not to have a normative text.

Let me close this bug and file another bug to support disconnected nodes in the spec.

The point is that the most of Shadow DOM spec has been written so that it only supports connected nodes. This motivation of this bug 24421 is make this fact clear so that there is no ambiguous parts in the current specification.

There has been a lot of ambiguous parts if we should consider connected nodes.
The current spec is not ready to accept disconnected nodes.
Let me work on this non-trivial task as another issue.

Filed as https://www.w3.org/Bugs/Public/show_bug.cgi?id=24627

(In reply to Hayato Ito from comment #12)
> There has been a lot of ambiguous parts if we should consider connected
> nodes.

s/connected nodes/disconnected nodes/