This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Add "isolated" flag to the plumbing, which would: * Make shadow DOM nodes have a different owner doc * Eliminate paths for reaching DOM information outside
* also need to re-create event object * prototypes that it sees need to be from that other frame.
For context, could you explain a use case for "isolated"? It would seem that just getting a reference to the host or ShadowRoot across different security contexts will be thwarted by existing SOP protections. One case that might be interesting is if attaching a ShadowRoot to an iframe has special semantics and <content> element there can pick children of the frame’s content document’s body. > * Eliminate paths for reaching DOM information outside Do changes to lower boundary encapsulation, where event handlers attached in the Shadow DOM can observe elements in the light DOM which were distributed into the shadow, need to be special-cased for isolated Shadow DOM? > * prototypes that it sees need to be from that other frame. I believe that this is already the case, for example if you do new ShadowRoot(e) where e is an element from a frame but new ShadowRoot is run in the context of another frame/parent frame/etc. See my comments on bug 17447.
Also needs to have a different scripting context.
Are there any use cases of projection with isolation?
Besides DOM encapsulation, a separate scripting environment (different world or global object), and a separate owner document and set of DOM prototypes, full isolation also requires a way to sanitize JS values that are passed to or returned from exported methods (something like the Worker structured clone algorithm but at minimum it also needs to be able to handle DOM nodes that have different wrappers inside and outside the component).
*** This bug has been marked as a duplicate of bug 20144 ***