Re: [w3c/webcomponents] shadow tree -> iframe <- contentWindow.frameElement encapsulation issue (#507)

> How would that help with anything? the iframe can load another same origin page and frameElement gets set back to the original value. Or document.open() used after parsing the page creates a new Window object too and ends up replacing frameElement.

`document.open` can be overridden and the window _unload_ event can be handled.  I'm not sure how easy timing would be in the latter case but if `postMessage` is used it should be possible to rerun your initial setup on the iframe immediately after the new window is created.

> I would expect that usually if one has iframe in shadow DOM for same-origin stuff, one actually wants to let that iframe contents to access the iframe, since that content is now part of the (possibly encapsulate) component. 

Yeah I'm not sure about this since, typically, a component would use an iframe for either encapsulation—which is superseded by shadow DOM—or cross-origin/sandboxing where `frameElement` would be null anyway.  Now that we have shadow DOM, I can't imagine many use cases for an iframe inside a shadow tree that another shadow tree wouldn't solve, except for working like a custom iframe.  But maybe they're there and I just can't think of them right now.

> But adding something like iframe.setFrameElement(Element anyElement); doesn't feel too bad.
Then it would be up to the custom element ctor or some such to call that method if one wants to override the frameElement. And it would work whether or not iframe is in shadow DOM. No special cases there. Just working the same way consistently everywhere.

I'm not against this idea, or one that looks at a larger picture by simplifying providing persistent custom elements, methods and properties to an iframe window (which would also cover other aspects of my use case).  Perhaps an event that triggered when the iframe's document object is created but before any parsing is done.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/507#issuecomment-222244272