What happens for an attempted network access with allow-network-access-upon-activation?

[ericfs]

It sounds like this Feature Policy would prohibit network access before activation, but how is the accomplished? Will any attempted network access immediately fail before activation?

If so, can network access be delayed until activation instead of failing? This could be simpler for developers to reason about than needing to worry about the lifecycle state of the document.

For example, if any image is included in markup, extra error handling would be needed to load the image after activation. If the network access is silently delayed then the image would load after activation with no additional work by the page developer.

Somewhat inspired by discussion in https://github.com/KenjiBaheux/portals/issues/2#issuecomment-395803308

[KenjiBaheux]

I agree that queuing would be more ergonomic that plain failing.

In the case of HTML elements in particular, it seems uncontroversial to delay firing the request until activation.

However, for JS triggered requests (e.g. fetch API), it seems preferable to have them fail. The code should be written to deal with failures. Otherwise, we might block a lot of work on delayed requests?

@nyaxt: any concerns with these behaviors?

[nyaxt]

I think suspending prohibited network fetches and resuming them on activation could work in Blink. I think we just need to experiment.

[ericfs]

I think JS triggered requests could also benefit form delay for the same reason, though the cost of handling errors is obviously much smaller when you're already writing JS. I still think it could help avoid developers needing to think a lot about lifecycle states. Though I suppose it's debatable whether that is a goal.

Similarly, I was going to ask the same question about access to local state. If JS triggered requests should produce errors, then it seems like JS triggered access to local state would also produce errors. I'll file a separate issue for this.

[ericfs]

Submitted #10

[dvoytenko]

One thing I'd like to note: network access to the same domain from which a document has been loaded should be safe. Not sure if we want to make that exception. This would, of course, include a family of such domains defined by either eTLD+1 or maybe a viewer could define a set of safe domains when constructing a portal.

[domenic]

Note that this issue more properly would belong on whatever feature/document policy repository is planning to spec the network access feature/document policy. We can leave it here for now, but I'm noting that for triage purposes.