What happens for an attempted network access with allow-network-access-upon-activation? about portals HOT 6 OPEN

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?

from portals.

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

from portals.

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.

from portals.

Submitted #10

from portals.

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.

from portals.

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.

from portals.