Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

History and window.frames #2

Closed
annevk opened this issue Feb 5, 2020 · 4 comments
Closed

History and window.frames #2

annevk opened this issue Feb 5, 2020 · 4 comments

Comments

@annevk
Copy link

annevk commented Feb 5, 2020

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.,

  1. Only first-parties (origin-bound, as per COOP+COEP) can push to history. History API is a complete no-op for third-parties.
  2. You can no longer enumerate on WindowProxy. Instead there's a same-origin property that gives you all WindowProxy objects for your origin. frame.contentWindow, window.parent, and window.top should 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".)

@annevk
Copy link
Author

annevk commented Feb 5, 2020

(I guess another channel is the load event as discussed at shivanigithub/http-cache-partitioning#2 (comment) onward.)

@mikewest
Copy link
Owner

mikewest commented Feb 5, 2020

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]?

@annevk
Copy link
Author

annevk commented Feb 11, 2020

I filed whatwg/html#5272 and whatwg/html#5273 with this a tiny bit flushed out.

@mikewest
Copy link
Owner

mikewest commented May 1, 2024

Archiving this repo, closing this out in favor of the bugs you filed (that we unfortunately didn't make much progress on).

@mikewest mikewest closed this as completed May 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants