History and window.frames
Closed this issue · 4 comments
I don't really want to tie this directly to COOP+COEP since they are so close (though maybe a future version?), but I think we can do more than accept the status quo for these features. (Saying COOP+COEP is the best possible answer is similar to saying that X-Frame-Options is the best possible answer for them, no?)
E.g.,
- Only first-parties (origin-bound, as per COOP+COEP) can push to history. History API is a complete no-op for third-parties.
- You can no longer enumerate on
WindowProxy. Instead there's a same-origin property that gives you allWindowProxyobjects for your origin.frame.contentWindow,window.parent, andwindow.topshould probably still be there, but might also be worthy of further scrutiny.
Any other such channels I overlooked should be tackled at the same time.
(In response to w3ctag/design-reviews#471 (comment) as I didn't want to get too "off-topic".)
(I guess another channel is the load event as discussed at shivanigithub/http-cache-partitioning#2 (comment) onward.)
I doubt anyone things COOP/COEP is the "best possible" solution for much of anything. :)
I also didn't want to get too off-topic in that other thread, but was also thinking that changing the APIs was probably a more reasonable approach than applying [SecureContext=Isolation] to them, especially in the short-term.
The kinds of proposals you've sketched above seem pretty reasonable to me. I was thinking of worse things like splitting WindowProxy into CrossOriginWindowProxy and SameOriginWindowProxy; special-purpose APIs to pull same-origin data feels better. @arturjanc might also have some opinions about quick fixes that we could deploy at Google.
Perhaps we can move this issue to HTML, and get it done, regardless of what we do with [SecureContext]?
I filed whatwg/html#5272 and whatwg/html#5273 with this a tiny bit flushed out.
Archiving this repo, closing this out in favor of the bugs you filed (that we unfortunately didn't make much progress on).