-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creator browsing context state #2508
Comments
It just so happens that there are "is active" checks all over Blink's Fullscreen implementation, preconditions that I haven't figured out if they should be spec'd or if they're there to bail out in cases where it shouldn't be observable. I'd be unsurprised if it is observable. These checks aren't done when traversing ancestors though. |
I think in particular requesting fullscreen from onclick in a current (fully active) document on a document that's navigated away from would be the kind of thing that is observable there and wrong in the current standard. |
Do you mean if the fullscreen resize is racing with the navigation? Yes, that seems likely to be broken. |
I was actually not considering races, just holding a reference to the previous document. |
Oh, now I see what you mean. Because of the active check's in Blink's implementation, that would be a no-op, it wouldn't even fire a fullscreenerror event. (One could try, but we don't dispatch events in inactive documents, which I assume is also not accounted for by any standard.) |
Well, the event loop processing model does say not to run in inactive (/ not fully active?) documents so that would match. I guess the other thing is that in Blink such a document can never become active again, whereas in Firefox it can (and other browsers that implement a theoretical "fast back" feature). |
https://w3c.github.io/webappsec-csp/ defines "embedding document" so something like that is probably needed. |
In #792 I flattened the concept of a creator document into several smaller slots so we store less data overall and create less of a chance for other standards to require leaking large parts of a document.
However, as pointed out in #2480 due to browsing context container and in particular nested through, we end up leaking the entire document anyway, except for the opener browsing context scenario.
It seems there's some duplication here that we could clean up, probably best done through studying the various places that make use of this mechanism:
The text was updated successfully, but these errors were encountered: