object/embed

[annevk]

Depending on the response, object/embed either create a browsing context or are embedding elements.

Service workers do not allow for this design as elements that create nested browsing contexts would always go through their own service worker.

Therefore these elements either become wormholes or will never be able to create a nested browsing context once you active a service worker.

This seems bad.

[jakearchibald]

If typemustmatch and type indicates a new browsing context, we can safely treat this like iframe. But yeah, the ambiguous case is a real problem.

[jakearchibald]

We can overcome this if we ignore type from the server and go with the type set on the element (with something like text/plain as a default).

Nasty little change in behaviour, but can't think of another way. I guess this would have to apply to all objects/embeds on controlled pages.

[michael-nordman]

@annevk, can you briefly describe the case(s) where an object/embed results in a new browsing context?

[annevk]

@michael-nordman, if you load an SVG resource for instance. See the HTML standard for all the details.

[jyasskin]

Looks like http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-embed-element-setup-steps and http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#object-type-detection have the details. For appcache, it says,

Note: In certain situations, e.g. if the resource was fetched from an application cache but it is an HTML file with a manifest attribute that points to a different application cache manifest, the navigation of the browsing context will be restarted so as to load the resource afresh from the network or a different application cache. Even if the resource is then found to have a different type, it is still used as part of a nested browsing context: only the navigate algorithm is restarted, not this object algorithm.

(I haven't found the normative wording corresponding to that note.) For service workers, would it make sense to do that double-fetch too?

Alternately, could it make sense to treat <object> and <embed> lookups as always using the service worker of the source browsing context, even if they create a nested browsing context? Is there a reason I've missed to maintain the invariant that nested browsing contexts always use their own service worker?

[jakearchibald]

Hah, of course, app cache would have the same problem.

It's a horrible hack, but if the plumbing is already there in the spec, we may as well use as much of it as we can. So:

1. If we know ahead of time, with certainty, that the object/embed will create a new SW client[1], treat like iframe (as in, it's a navigate, it selects a SW registration based on the request url)
2. Else use the current SW of the document for the request
3. If the response would result in a new client (browsing context in this case), abandon this response & start again, treating it like iframe

Alternately, could it make sense to treat <object> and <embed> lookups as always using the service worker of the source browsing context, even if they create a nested browsing context?

We don't allow you to provide a non-redirect OpaqueResponse to a new-client request, as that would give you a shot at the resources within, and those request objects violate the opaqueness. Also, if you visit jakearchibald.com and I have a SW and include a context-making embed to google.com, but satisfy that response with something I create myself, do I now have script access to google.com?

[1] @annevk pointed out that it's not just navigations that "select" a SW registration to use, as shared workers do too

[jakearchibald]

If the initiator may allow a plugin to handle the response, it should be requested with the skip service worker flag, as should any requests made by those plugins.

Flash gets its security origin from its own url, so we can't let the page's ServiceWorker handle it. As for subresources, stuff like cross-domain.xml is similar to XHR preflight, so cannot go through any SW.

We should avoid SW+plugins for now, and we can spec how to handle individual plugins once we fully understand the security implications. Or hey, maybe plugins will die before we get there :trollface:

[annevk]

That means we need to special case requests whose context is embed or object in the specification.

[KenjiBaheux]

Avoiding SW interactions with plugins for now sounds reasonable.

[jungkees]

Special cased embed and object contexts in Handle Fetch for now: a05e8d8c6a124bc58ce5c89faa59e26d5d31ec4e.

[annevk]

Note that this affects more than plugins.

[jungkees]

I think we can close this issue for now.

[annevk]

Why? Don't we ever want to address this?

[jungkees]

I thought returning null for potential client requests in Handle Fetch makes sense, and we didn't come up with any further discussion for that.

Let's think about that then. Re-opening.

[annevk]

We should perhaps introduce attributes in HTML that lock these elements to being either a browsing context or embedding context (upon insertion or some such) and then service workers can work with them.

[jakearchibald]

I think the type attr can do that?

On Thu, 12 Mar 2015 15:34 Anne van Kesteren notifications@github.com wrote:

We should perhaps introduce attributes in HTML that lock these elements to being either a browsing context or embedding context (upon insertion or some such) and then service workers can work with them.

— Reply to this email directly or view it on GitHub https://github.com/slightlyoff/ServiceWorker/issues/249#issuecomment-78504297 .

[annevk]

For object I think that typemustmatch would also have to be set. But yeah, some set of rules around that would probably do the trick.

[patrickkettner]

To clarify - there is currently no way for a SW to serve a swf file that is defined as the data attribute on an object/embed, correct?

[annevk]

Correct.

[babatakao]

Because of this issue, it is hard to use SVG on SW. Since images referenced from SVG specified by are not shown, it is needed to use <object>. (iframe or inline SVG may be the solution, but they cannot be always adopted.)

There are no activity for long time. Any plan to address it?

[jakearchibald]

Iframe is definitely the closest thing right now. Although <img> works if you don't need scripting, and as you say there's inline SVG.

Can you go into a bit more details in terms of why iframe doesn't work as a solution here?

[babatakao]

The root cause is for the existing contents. I assume an EPUB reading system. Quite a lot of EPUB files use object to load SVG.

[jakearchibald]

We can only solve this if we know in advance whether the <object> will create a browsing context or not. That means setting the type, and whatever ensures strict type matching (it used to be typemustmatch but that seems to be gone now, replaced with X-Content-Type-Options: nosniff perhaps?).

However, if you're saying that this problem only exists when existing contents cannot be changed, then there's no point us fixing it, as it would still depend on existing content changing.

[babatakao]

Thank you, I've understood the difficulty.

Just on the use case I assumed, most of <object> elements already have type attribute and it's easy to add "X-Content-Type-Options" header. So conditional support for object element is welcome.

That said, I will consider the way to modify contents with iframe.

[zcorpan]

It seems that object creates a browsing context for images, documents and SVGs in Chromium and WebKit. In Gecko, images do not create a browsing context. Also see https://github.com/whatwg/html/issues/7939

• object https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13106
• embed https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13107

Does that change the situation for this issue?

Also related is the YouTube embed rewrite issue, and whether that should create a browsing context, see https://github.com/whatwg/html/issues/2390#issuecomment-2363164672