<iframe> and Window's named properties

[hayatoito]

Title: [Shadow](assuming iframes should work inside shadow DOM) Should the contentWindow objects of iframes in shadow DOM show up in window.frames? (bugzilla: 28086)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28086

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28086#c0
Olli Pettay wrote on 2015-02-23 23:28:45 +0000.

.

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28086#c1
Tab Atkins Jr. wrote on 2015-02-24 02:27:14 +0000.

Kneejerk reaction: no, it shouldn't, because the contents of the shadow DOM should be hidden by default.

(And yes, iframes totally work inside shadow DOM, why wouldn't they?)

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28086#c2
Olli Pettay wrote on 2015-02-24 13:16:01 +0000.

Yeah, I agree it shouldn't, but per specs... well, not sure, because
iframe handling in shadow DOM isn't really spec'ed.

(iframes shouldn't per current specs work in shadow DOM.
https://code.google.com/p/chromium/issues/detail?id=393350

Afaik everyone agrees they they should work,
but there are several spec bugs to fix.
Like this and bug 27325 and bug 26365)

[annevk]

So if an <iframe> works it becomes a "child browsing context" and it'll be "nested through" so we'll need to carefully vet everything that talks about that (and update it to account for shadow trees existing), including indeed the named properties on Window.

I think that for named properties it would make sense to not expose <iframe> from a shadow tree, whether it's open or closed. That would match what we do for activeElement and such. @smaug----, makes sense?

[smaug----]

Makes sense.

(There are other related issues too, I think even bugs filed, about iframes in shadow DOM. For example how should history API work?)

[hayatoito]

The basic rule should be:

• Do not leak any node, name or anything else about a shadow tree via any existing APIs. We do not want developers to access shadow trees unintentionally.
• It's okay to access a node in an open shadow tree via new API, e.g. Element.shadowRoot, Element.getAssingedSlot, Event.deepPath(), because there is an explicit intention.
• Never allow to access a closed shadow tree, even when an author uses a new API. e.g. Element.shadowRoot should return null for a closed shadow tree.

We might want to judge case by case carefully, however, we should honer this basic rule as possible as we can.

In a strict sense, we should use an "unclosed node" in this rule because it's okay to see a node in the parent tree.

[annevk]

That matches my assumptions. @smaug---- that would be #184. I'm not entirely sure how that should work, but we can discuss it there.

[TakayoshiKochi]

For this issue, can we conclude that

• window named properties will not include any names from <iframe>s in shadow tree, whether it is open or closed
• window.frames won't inlcude <iframe>s in shadow tree, whether it is open or closed

and close?

[TakayoshiKochi]

Ah, I didn't understand window and window.frames are the same object :-(
The second bullet should be

• window.length does not count <iframe>s in shadow tree, whether it is open or closed

then.

https://html.spec.whatwg.org/multipage/browsers.html#accessing-other-browsing-contexts
says

... is the number of child browsing contexts that are nested through elements that are in a Document ...

so we don't have to touch the spec, either.

[annevk]

I think we do, since the named property access text is not as precise at the moment...

[TakayoshiKochi]

I think we do, since the named property access text is not as precise at the moment...

Ah, okay, I'll take a look today.

[annevk]

Sorry for not saying something sooner, but I think once whatwg/html#1312 lands this should not be too hard to define as an addition to that algorithm.

[TakayoshiKochi]

Thanks, it helps.

[hayatoito]

@TakayoshiKochi It looks whatwg/html#1312 was merged. Do you have any action item for this issue?

[domenic]

There is an action item here. We need to update https://html.spec.whatwg.org/#child-browsing-context and decide whether to change "in a document" to "in a document tree" or "is connected".

It may be possible that we need to change it to "is connected" for other parts of the spec to make sense, but we still want to not include browsing context names unless they are "in a document tree". In that case we should both update the definition of child browsing context, but also update https://html.spec.whatwg.org/#child-browsing-context-name-property-set to add an additional "in a document tree" check (or some similar check that the browsing context container's root is a document). That seems most likely.

Let's assign this to me. I was recently messing with child browsing context stuff and can take this on. It sounds like there is consensus to not include them in the name property set.

[annevk]

@domenic in particular note the sibling issue #184 for the other things that would need updating around <iframe> (and nested browsing contexts in general come to think of it, it isn't really <iframe> specific unless we only make <iframe> work in shadow trees).

[domenic]

Oh :(. I really don't want to solve #184 here as that seems to have turned into a super-complex idea that overhauls how history works in browser implementations.

Maybe I will leave "in a document" in the definition of child browsing context to reflect that we are unsure about #184, but add an additional "in a document tree" check to the browsing context names check for a targeted fix there.

[domenic]

Should iframeWindow.parent give back the parent when the corresponding <iframe> is in a shadow tree? I am going to assume yes for now.

[domenic]

I have a pull request for this at whatwg/html#1625. I assumed that #536 would be resolved in favor of not using other elements' ids and names in the named properties.

[smaug----]

Should iframeWindow.parent give back the parent when the corresponding <iframe> is in a shadow tree? I am going to assume yes for now.

yes, at least as long as we don't have any stronger encapsulation than 'closed'.