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

[annevk]

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