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

> Opt-in, maybe, but that's easy if WebKit fix their non-configurable frameElement binding.

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.

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. 
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.

---
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-222182716