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

> > Still, both cases run through the same navigation architecture in Chrome, and we make a decision about whether to commit into a new browsing context vs. render the result.
>
> I'm not sure that's the whole story, by the way.

All I was saying here is that the outgoing request runs through `NavigationRequest` in Chromium. I haven't dug into that code enough to determine where we make the decision that it really isn't a navigation, and ought to have different Blink-side behavior, because I agree with you that it is, in fact different. :)

This is getting a little bit into the weeds, though. I'd like to get us back to the high-level question of how the `mode` and `destination` of `<embed>` and `<object>` _ought_ to work, assuming that we can change how they _do_ work today. Given the presence of plugins today, the proposal in https://github.com/whatwg/fetch/pull/948#issuecomment-543560997 still seems reasonable to me (the initial request (and subsequent requests that modify the `<embed>` directly sends `no-cors`/`embed` as they might cause plugin creation, whereas requests that navigate a browsing context created in the `<embed>` would send `navigate`/`embed`).

If we can do away with plugins, and stop special-casing images, then `navigate`/`embed` might be appropriate for everything?

-- 
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-547312642