Bug 19562 - [Shadow]: Consider making shadow DOM subtrees public by default
[Shadow]: Consider making shadow DOM subtrees public by default
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 normal
: ---
Assigned To: Dimitri Glazkov
public-webapps-bugzilla
:
: 15409 (view as bug list)
Depends on:
Blocks: 18428
  Show dependency treegraph
 
Reported: 2012-10-16 21:14 UTC by Dimitri Glazkov
Modified: 2012-11-28 21:13 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2012-10-16 21:14:39 UTC
This is a spill-over from bug 15409.

There's been several comments from developers about the fact that Shadow DOM encapsulation is _too_ well-sealed for various long tail, but important use cases. In other words, the information that could be accessible (no security concerns, for example) is not. One has to use hacks to get at the truth.

A proposed solution strawman:

I buy this and want to help. Here's the latest strawman:

1) There's a 3-position switch on each shadow DOM subtree: public,
private, isolated.

2) There's a mechanism in place to flip this switch (specifics TBD)

3) the element.shadowRoot property points to the top of the tree
stack, or null if the shadowRoot's subtree is in "private" or
"isolated" setting.

4) <shadow>.olderSubtree points to the older subtree in the stack or
null if the older subtree is in "private" or "isolated" setting.

5) ShadowRoot.host points to the shadow host or null, if the subtree
is in "private" or "isolated" setting.

6) The "isolated" setting essentially means that there's a new
document and scripting context for this shadow subtree (specifics
TBD). Watch https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509 for
progress.

Remaining questions:

a) how is the switch flipped and when?

b) do we want to introduce the concept of removing shadows subtrees
from the top of the stack? Seems like a completeness thing.
Comment 1 Dimitri Glazkov 2012-10-16 21:16:41 UTC
*** Bug 15409 has been marked as a duplicate of this bug. ***
Comment 2 Sooel Son 2012-11-10 16:51:19 UTC
I found that simple code from the previous thread (bug 15409)
Therefore, I like to ask you a question about the following code instance. 

var shadows = new WeakMap();
(function () {
  var realCtor = ShadowRoot;
  ShadowRoot = function (host) {
    var shadow = realCtor(host);
    var hostShadows = shadows.get(host);
    if (!hostShadows) {
      hostShadows = [];
      shadows.set(host, hostShadows);
    }
    hostShadows.push(shadow);
    return shadow;
  };
})();

JavaScript closure can hide a shadow root instance from the hosting page or other scripts running on the same orgin. However, because the hosting page can redefine ShadowRoot, the shadow root can be accessible to other scripts via the following code. 

window.ShadowRoot = function(e) { 
  window.hook_shadowRoots.push(e);
  e = new ShadowRoot(e);
}

I understand that Shadow DOM does not provide security isolated environment. However, it can be used at hiding DOM elements even from the same origin with the help of JavaScript closure. 

My question is simple. Is it possible? or There is no plan at all to support this scheme.
Comment 3 Dimitri Glazkov 2012-11-20 00:27:10 UTC
http://dvcs.w3.org/hg/webcomponents/rev/89362bed5080
Comment 4 Dimitri Glazkov 2012-11-28 21:09:41 UTC
http://dvcs.w3.org/hg/webcomponents/rev/03ee269f46b1
Comment 5 Dimitri Glazkov 2012-11-28 21:13:04 UTC
http://dvcs.w3.org/hg/webcomponents/rev/0714c60f265d