How to block user-visible APIs pre-activation?

[domenic]

As discussed in https://github.com/jeremyroman/alternate-loading-modes/blob/gh-pages/browsing-context.md, we need to block access to a variety of user-visible APIs pre-activation. There are at least two ways to do this:

1. Have the APIs immediately fail. E.g. alert() would return without showing anything; window.open() would return null; permission-prompting APIs would immediately reject, as if the user had rejected.

2. Have the APIs delay as much as possible until activation. What this means for each API is subtle. For permission-prompting APIs, it would show the prompt after activation. But for something like alert(), would it block the event loop? For window.open(), would it open a "background window", and then upon activation start showing the until-now-hidden window?

3. A variant of (2), where we don't just delay that particular call, but we freeze the entire document upon any such call. This could make it less likely for other tasks on the event loop to get confused by the hanging promise.

[jeremyroman]

A dogmatic option 2 seems bad. As you say, we can't just block the event loop during alert. Opening windows during prerendering is bad and there's a ton of precedent there from popup blockers. I suspect that overall we're a mix is probably appropriate.

My gut:

• alert, confirm, prompt, print: no-op; return empty-ish value
• window.open: no-op, as though popup had been blocked
• permission request: hang waiting for permission; proceeds on nav (prompting if needed)
• (if network restrictions are incorporated) fetch: hang on unauthorized request except for sync XHR, which fails
• storage APIs: blocked, for consistency with one another

I'm sure @mfalken and prerender folks have thoughts.

[domenic]

We've got a stab at this in #16 (based on this document). I think this is largely settled, although #7 remains open as synchronous storage and service workers are complicated and not yet settled.