Creator browsing context state

[annevk]

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:

• Secure contexts
• Fullscreen (it seems Fullscreen should just require the document to be fully active; needs tests)
• Usage inside HTML
• ...?

[foolip]

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.

[annevk]

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.

[foolip]

Do you mean if the fullscreen resize is racing with the navigation? Yes, that seems likely to be broken.

[annevk]

I was actually not considering races, just holding a reference to the previous document.

[foolip]

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

[annevk]

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

[annevk]

https://w3c.github.io/webappsec-csp/ defines "embedding document" so something like that is probably needed.