Explicit behavior for removing last NetworkIntercept

[Lightning00Blade]

Currently there is an implicit behavior when removing the last intercept from the session's intercept map.
Let's say we do the following steps:

1. We subscribe to the network module
2. We add network interception for URL A (phase BeforeRequestSent).
3. We make a fetch request from the page to URL A.
4. The BeforeRequestSent get emitted and event get a isBlocked: true and intecepts: [ "<ID>" ]
5. We remove the network interception.
6. The request continues to wait for a network.continueRequest command

The question here is if this would be the expected from the user?

I think we should either:

• Mention this behavior explicitly as a note in the network.removeIntercept command.
• Fail the network.removeIntercept command when there are request in-flight that are being blocked only by this.
• Continue the request as if the network.continueRequest command were called.

Note: This was discovered as CDP's behavior is to continue the request if interception is removed.

[juliandescottes]

The first option sounds good. Since the intercept is only really necessary to block the request I think the current behavior is fine, and calling it out explicitly in the spec could be enough.

[OrKoN]

I think it's worth mentioning as non-normative note (first option) because the spec already defined this behavior. About CDP implementation: we will need to keep the interception on, until the last request is handled, and auto-continue new requests.