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

[farre]

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 <iframe> has been a topic before and feels like a pretty safe change now that we're considering deprecating <object> and <embed> for images.

[domenic]

I am extremely enthusiastic about this, if you think we can get away with it compatibly.

The other thing this probably breaks (unless you add back in some different complications) is fallback for <object>; see #7327 for discussion there, including some use counter data. I guess <embed> also has special display for the error case, but I'm not sure if that's web-observable.

[domenic]

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

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.

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 <object>'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 <object>, or would we add some kind of hack to resize the <object> once the response comes back if it's an image, even though that image is going into a nested browsing context?

[farre]

Exactly, only bad-response or that there will be a nested browsing context.

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 <object> embedded image from its embedder. I've found exactly the sizing issue, but also three other issues:

1. There is at least one style that needs to be propagated to the wrapped image, namely image-rendering. 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.

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

The thing that's stumped me is what to do about Windows.frames and named targeting, which is why I wanted to know if it would be possible to adjust the spec to allow this.

This is only my opinion, but I'd much rather have <object> and <embed> 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. video/webm, at least if you consider how both Firefox and Chrome implement embedding of media resources in <object>.

What to do about styling I'm not that sure of though.

[domenic]

In general I'd be happy to adjust the spec to anything web-compatible that moves embed/object closer to iframe. That includes window.frames, named targeting, and sizing. Figuring out the compat burden is the hard part though.

[domenic]

@mfreed7 maybe you or your team could help determine the compat impact of removing the auto-sizing, by adding a use counter?

My understanding based on some quick tests is that <embed> and <object> both get some sort of intrinsic size set, when they host a SVG. I think it is only when they host a SVG, but I am not sure. See http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10404.

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.

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 width="" and/or height="" attributes override those to); calculate the sizes with this intrinsic size info; and then see on what percentage of pages that mismatches.

[mfreed7]

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.

Tracking bug here: https://crbug.com/1340033