This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20144 - [Shadow]: Add "closed" flag to createShadowRoot
Summary: [Shadow]: Add "closed" flag to createShadowRoot
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
: 16509 23134 (view as bug list)
Depends on: 23134 28445
Blocks: 25330 27325 28552
  Show dependency treegraph
Reported: 2012-11-28 22:59 UTC by Dimitri Glazkov
Modified: 2015-12-03 07:43 UTC (History)
14 users (show)

See Also:


Description Dimitri Glazkov 2012-11-28 22:59:01 UTC
A tree created with this flag set to true will not appear in the shadow DOM traversal API.
Comment 1 Dimitri Glazkov 2012-11-28 23:01:52 UTC
It seems that having a distinction of a "private" shadow tree is a misnomer, possibly giving the author a false hope that their shadow tree is somehow protected from a motivated owner of the document. Unfortunately, that's not the case -- the document can easily override and capture all shadow trees created, thus killing the shadow author's illusion of privacy.
Comment 2 Dominic Cooney 2013-04-25 04:54:09 UTC
This public-webapps thread is informative: <>
Comment 3 Edward O'Connor 2014-02-07 23:23:01 UTC
So, any progress on this?

(I'm not sure if you are using Bugzilla's Importance field; if so, I bumped this up to P1 given recent discussions.)
Comment 4 Dimitri Glazkov 2014-02-11 23:28:09 UTC
(In reply to Edward O'Connor from comment #3)
> So, any progress on this?

Not yet. But it's still on the radar.

BTW, this should also disable access via relevant CSS selectors (
Comment 5 Maciej Stachowiak 2014-02-12 01:18:08 UTC
Suggestion: how about instead of private vs public, the flag is "open" vs "closed"? That won't unduly promise security isolation. Then a hypothetical third truly secure mode could be called "secure" or "sandboxed" and it would be consistent.
Comment 6 Dimitri Glazkov 2014-02-13 21:47:01 UTC
This public-webapps thread is informative:
Comment 7 brian kardell 2014-02-24 19:56:55 UTC
It seems to me that there are different concerns you might talk about, not entirely unlike sandboxed iframes.  Shadow DOM (as currently) provides a nice simple membrane to keep lots of accidental things from going wrong, but can be easily traversed into/pierced and doesn't get a separate execution context or anything special.  If we had a ::parts concept it would be useful to explain what that means in terms of CSS and DOM boundaries, etc.

Is it possible to consider, instead of a flag, that a shadow root has a set of properties (which I hope default to what they currently are in canary, personally).  This would probably help explain things in the platform even if we never entirely enable them in author space, if you see what I am saying.
Comment 8 Hayato Ito 2014-11-19 04:49:40 UTC
*** Bug 16509 has been marked as a duplicate of this bug. ***
Comment 9 Hayato Ito 2015-02-10 08:44:08 UTC
Let me change the subject of this bug since I am feeling that we tend to use 'closed' rather than 'private'.
Comment 10 Hayato Ito 2015-02-10 08:48:29 UTC
*** Bug 23134 has been marked as a duplicate of this bug. ***
Comment 11 Dylan Barrell 2015-03-10 21:47:48 UTC
(In reply to Hayato Ito from comment #10)
> *** Bug 23134 has been marked as a duplicate of this bug. ***

Please consider my concerns raised in this comment
Comment 12 Maciej Stachowiak 2015-04-22 01:26:46 UTC
It looks like 'closed' mode has been added to the spec, but not yet a way to enter it (this bug) or a spec of its behavior (bug 27775).
Comment 13 Hayato Ito 2015-04-22 16:54:29 UTC
The status of the behavior of the closed mode is still WIP. There are still remaining tasks. I have to address how event.path() should work for closed shadow trees further at least.

What's the more important is that we don't have a clear idea how open / closed interact in multiple shadow trees. I'm still investigating.
Comment 14 Maciej Stachowiak 2015-04-22 17:00:48 UTC
Does adding a parameter to createShadowRoot() require solving all those problems first?
Comment 15 Hayato Ito 2015-04-22 17:07:36 UTC
(In reply to Maciej Stachowiak from comment #14)
> Does adding a parameter to createShadowRoot() require solving all those
> problems first?

Good question. No. This bug shouldn't depends on bug 27775 strictly in terms of the spec. We can do in parallel!

Let's move this bug forward.

I think the proposal so far is to make createShadowRoot() can take one optional dictionary, such as:

- createShadowRoot({'mode': [closed/open]})

Is there any other proposal?
Comment 16 Hayato Ito 2015-04-22 17:09:55 UTC
Unless there is any other proposal, let's me spec that tentatively.
Comment 17 Hayato Ito 2015-04-22 18:13:40 UTC
Done tentatively at

I appreciate any feedbacks.
Comment 18 Maciej Stachowiak 2015-04-23 21:52:57 UTC
Looks like a good starting point for the API. Thanks! I think the remaining issues are captured in bug 27775 (to define the behavior) and bug 28445 (to determine the default) so I think it would be reasonable to close this bug now.
Comment 19 Hayato Ito 2015-04-27 03:03:50 UTC
Let me reopen this.
Now ShadowRootInit should be mandatory.
Comment 20 Domenic Denicola 2015-04-27 03:50:46 UTC
There is also the issue of naming. At the F2F many people were saying that "closed" vs. "open" is not a good name for this because the existing mode is fairly closed already.

I offer { censored: true }/{censored: false } since its primary function is to censor shadowRoot, deepPath, and any other future properties.
Comment 21 Anne 2015-04-27 08:03:00 UTC
How about visible/hidden/isolated?
Comment 22 Olli Pettay 2015-04-27 17:06:39 UTC
censored doesn't really say much, IMO.

visible, hidden, isolated - I think I like that.

(better than public/protected/private)
Comment 23 Domenic Denicola 2015-04-27 17:09:12 UTC
"visible" still doesn't seem correct. Unless you are using visible to refer to the light DOM, and hidden is { closed: true }?
Comment 24 Olli Pettay 2015-04-27 17:13:42 UTC
"visible" when passed to createShadowRoot() quite naturally hints that the
created shadow root is visible to the outside users, no?
Comment 25 Domenic Denicola 2015-04-27 17:18:12 UTC
No, to me it hints that the resulting DOM is visible like normal DOM is, not that it's hidden from CSS selectors and from access without the .shadowRoot indirection.

I think if we want a spectrum of terms we need to have it include light DOM at one end. E.g.

- Light DOM: visible
- Shadow DOM: shadow
- Shadow DOM, censored access: hidden
- Shadow DOM, isolated global: isolated
Comment 26 Domenic Denicola 2015-04-27 17:19:45 UTC
Sorry, to clarify: I just want some straightforward terminology. We of course wouldn't allow .createShadowRoot({ mode: 'visible' }) in my scheme. I just want to talk about what mode a subtree is in and have a word for what mode it's in when there's no shadowey stuff going on.
Comment 27 Hayato Ito 2015-05-27 03:00:03 UTC
Moved to
Comment 28 Cris Stringfellow 2015-12-03 07:43:37 UTC
Don't make it impossible for scripts to access nodes in or distributed in a shadow tree. Why? What if we want to have privileged chrome code modify or read content from a page, to alter or enhance a page's behaviour? What if we want to programmatically interact with nodes within a shadow boundary? If scripts have no access to these... this is impossible. It is essentially a form of DRM for any content on the web. The workaround is to recompile Chrome from source and revert changes that introduce these restrictions, in effect forking the browser.