<embed> elements (HTMLEmbedElement) do not have contentWindow or contentDocument

[Rob--W]

HTML documents can be loaded with <iframe src>, <frame src>, <object data> and <embed src>.
The first three elements allow the content to be referenced via .contentWindow and .contentDocument. .contentWindow.postMessage can be used to communicate with the frame.

<embed> does not have these properties, and it is not straightforward to use postMessage with a document in an <embed>.

Presently, an API that internally operates on BrowsingContexts usually take a WindowProxy. This works for common cases, except for <embed>. For example, the window.postMessage API is designed to offer a cross-origin communication mechanism, but the absence of a .contentWindow property prevents this from being used with documents in <embed> elements ^{[note 1]}.

With the removal of plugin support from the web platform, I see no reason to not treat <embed> similarly as the other ways to embed documents. Ideally, HTMLEmbedElement should have an interface that's consistent with iframes, and at least include the contentWindow (and contentDocument) properties.
<object>s were also used for plugins, and nowadays they also have a .contentWindow: https://wpt.fyi/results/html/semantics/embedded-content/the-object-element/object-attributes.html

_{[note 1] window.frames[] does include windows from <embed>, but it is not possible to tell whether an item in window.frames[] belongs to a specific <embed>, except in the same-origin case, where frames[i].frameElement can be compared with an <embed> element.}

[annevk]

On the one hand this seems somewhat reasonable, but on the other hand we don't really want folks to use the embed and object elements going forward so I'm not sure why we'd invest in them. What reason do you have for using the embed element instead of iframe?

[Rob--W]

I would personally not use <embed> over <iframe>. Web pages may, and that's an issue for extensions, which cannot easily communicate with the right frame without .contentWindow.

In w3c/webextensions#12, there is a request for an extension API to allow extensions to communicate between content scripts (i.e. extension scripts that run in an execution environment that differs from the web page itself). Since extensions may operate on arbitrary pages, they may encounter <embed> elements.

Without .contentWindow on <embed>, the new extension API would not only need to accept WindowProxy, but also HTMLEmbedElement. And for consistency, also (i)frame and object elements.

With .contentWindow on <embed>, the new extension API can just take WindowProxy, without the need of being aware of <embed> or any other HTML element.

[annevk]

Can we expose element APIs to extensions only? It seems reasonable to use these names as we wouldn't ever use them for something else, but extensions is not a sufficient reason to expose them to websites directly.

[Rob--W]

Can we expose element APIs to extensions only?

At least in Firefox that is possible (and we use it very sparingly), but I cannot speak for all other implementations. For dangerous APIs, I see value in restricting them to extension use cases only, but I also believe that fragmentation of APIs should be avoided where possible. .contentWindow is a prevalent concept on the web platform, and limiting an obscure case to extensions only would cause confusion.

It seems reasonable to use these names as we wouldn't ever use them for something else, but extensions is not a sufficient reason to expose them to websites directly.

I mentioned a non-extension use case in the initial report, postMessage. Yes, it's possible to replace <embed> with <iframe>.
But it seems somewhat arbitrary that only one of the standard ways to embed HTML documents don't support the .contentWindow/.contentDocument accessors that other elements do have.

[domenic]

+1 for not adding anything to embed (outside extension APIs). We want to discourage use of it as much as possible, so feature gaps are good and should be preserved.

[smaug----]

I agree. Avoiding to add new features to embed or object is preferable.
In general I value consistency a lot, but in this case consistency might lead to people use legacy features more.

[annevk]

Removing agenda+ as I think there is a clear answer here at this point. @Rob--W are you okay with restricting this to extensions?

[Rob--W]

Since there seems to be broad consensus here to not add a contentWindow getter to <embed> elements, we won't go in that direction.

In the WECG we have decided to not add an extension-only embed.contentWindow getter, but let the proposed getFrameId API accept HTMLEmbedElement instances in addition to WindowProxy types.

[lzudor-omnitech]

Hi there,

This might be an abandoned topic yet still wanted to point out the advantage of object ( & embed) tag over iframe, which is the auto-sizing effect, while maintaining (axes) proportion (just like img tag), ideal for (animated) SVGs for instance.

Just noticed Firefox (from version 112+) returns now null for object.contentWindow if same domain policy is not met (however iframe is still working well), which seems a step back...