Make `<embed>` and `<object>` behave like `<iframe>` for image loading

I'd like to propose that we change how <embed> and <object> load resources with a type that starts with image/ to be like that what we have for media resources (e.g. <video>), and behave like "7.11.6 Page load processing model for media". This essentially means removing the special case for images in the <embed> and <object> setup steps, and will make <embed> and <object> behave more like <iframe> when loading images.

Making <embed> and <object> behave more like has been a topic <a rel="noreferrer nofollow" target="_blank" href="https://github.com/whatwg/fetch/pull/948">before</a> and feels like a pretty safe change now that we're <a rel="noreferrer nofollow" target="_blank" href="https://github.com/whatwg/html/issues/4592">considering deprecating</a> <code><object></code> and <code><embed></code> for images.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>I am extremely enthusiastic about this, if you think we can get away with it compatibly.</p> <p>The other thing this probably breaks (unless you add back in some different complications) is fallback for <code><object></code>; see <a href="https://github.com/whatwg/html/issues/7327">https://github.com/whatwg/html/issues/7327</a> for discussion there, including some use counter data. I guess <code><embed></code> also has special display for the error case, but I'm not sure if that's web-observable.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Hmm I think I misread your proposal as "make embed and object behave as browsing context containers like iframe that get navigated to the target URL", not "continue having their current setup but remove the image special case".</p> <p>In particular the current setup does not use the usual navigation algorithm, but instead uses a separate path to get the response, and then process that response as either an image, bad-response, or nested browsing context case. I guess you are suggesting sticking with the separate get-response and process-response stages, and just having process-response have only bad-response or nested browsing context cases.</p> <p>That could work, and does remove some of the risk of my full-unification plan. However the remaining issue (and also something we're not sure yet how to handle in #4592) is that <code><object></code>'s special sizing behavior for images is not something iframes support. iframes always have 300x150 size, unless you supply width=""/height="" attributes. Do you think we'd have the same behavior for <code><object></code>, or would we add some kind of hack to resize the <code><object></code> once the response comes back if it's an image, even though that image is going into a nested browsing context?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/farre"><img src="https://avatars.githubusercontent.com/u/776258?v=4" />farre</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>Exactly, only bad-response or that there will be a nested browsing context.</p> <p>I'm looking at this for Firefox in the context of ORB, since nesting an image load in a synthetic document would nicely separate a cross-origin <code><object></code> embedded image from its embedder. I've found exactly the sizing issue, but also three other issues:</p> <p>1) There is at least one style that needs to be propagated to the wrapped image, namely <code>image-rendering</code>. I haven't found more, but that doesn't mean that there aren't any, and this might need further investigation. 2) The fact that if embedding images result in a nested browsing context it also shows up in its parents Window.frames, but also: 3) This means that embedded images can now be name targeted when navigating.</p> <p>Implementation-wise, I've managed to perform the hack you describe to let the element know about the intrinsic size of the image, and I've also been able to implement propagation of <code>image-rendering</code>. </p> <p>The thing that's stumped me is what to do about <code>Windows.frames</code> and named targeting, which is why I wanted to know if it would be possible to adjust the spec to allow this.</p> <p>This is only my opinion, but I'd much rather have <code><object></code> and <code><embed></code> have 300x150 size unless otherwise specified as well as allowing embedded image containers to expose their browsing context's functionality as well. This would make images work like other media, e.g. <code>video/webm</code>, at least if you consider how both Firefox and Chrome implement embedding of media resources in <code><object></code>.</p> <p>What to do about styling I'm not that sure of though.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>In general I'd be happy to adjust the spec to anything web-compatible that moves embed/object closer to iframe. That includes <code>window.frames</code>, named targeting, and sizing. Figuring out the compat burden is the hard part though.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/domenic"><img src="https://avatars.githubusercontent.com/u/617481?v=4" />domenic</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>@mfreed7 maybe you or your team could help determine the compat impact of removing the auto-sizing, by adding a use counter?</p> <p>My understanding based on some quick tests is that <code><embed></code> and <code><object></code> both get some sort of intrinsic size set, when they host a SVG. I think it is <em>only</em> when they host a SVG, but I am not sure. See <a href="http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10404">http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10404</a>.</p> <p>This is an information leak from the hosted content to the outer page that we would like to remove. And it also makes embed/object extra-complicated. And it gives embed/object extra capabilities over iframe, which makes it harder to tell people to stop using embed/object.</p> <p>Could we add a use counter to tell in what situations this intrinsic size information affects the outer page? E.g. calculate the size without it (which would normally be 300x150, or whatever the <code>width=""</code> and/or <code>height=""</code> attributes override those to); calculate the sizes with this intrinsic size info; and then see on what percentage of pages that mismatches.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/mfreed7"><img src="https://avatars.githubusercontent.com/u/29559695?v=4" />mfreed7</a> commented <strong> 2 years ago</strong> </div> <div class="markdown-body"> <p>We can probably tackle that at some point soon. It might be a tricky thing to use count, since it might require doing extra layout work. But we can take a look.</p> <p>Tracking bug here: <a href="https://crbug.com/1340033">https://crbug.com/1340033</a></p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>

whatwg / html

Make `<embed>` and `<object>` behave like `<iframe>` for image loading #7939