Re: [whatwg/fetch] Split 'document' destination into 'frame' and 'iframe'. (#948)

> It's surprising that Chrome has apparently a very different model from this.

Chromium is nothing if not surprising. The challenge I'm thinking of is that we're currently keying the `Sec-Fetch-Dest` and `Sec-Fetch-Mode` header values off the framing element type (see https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_request.cc?rcl=5514046a3db301445a8e1c8aa23f638523e4f462&l=323 for example), and we run through the same codepath for the initial navigation from `<embed>` as we do for subsequent navigations. That is, Chromium treats the request in your step 1 as a navigation regardless of whether we're going to render it as a plugin or not. My recollection here is a bit fuzzy, but I think we end up synthesizing a [`PluginDocument`](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/plugin_document.h?q=plugindocument&dr=CSs&l=37) to hold the plugin, so when we extracted navigation from the renderer process, `<embed>` and `<object>` came right along with it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/948#issuecomment-544380893