emulation.setNetworkConditions:offline

[sadym-chromium]

First step addressing #776.

• Fail all the intercepted requests, WebSocket and WebTransport.
• Html spec: [WebDriver BiDi] emulate network offline whatwg/html#11575
• Fetch spec: [WebDriver BiDi] emulated network offline whatwg/fetch#1852

---

Preview | Diff

[juliandescottes]

Could we discuss this again with the working group (if it was discussed recently, I'm missing the summary) ?

[juliandescottes]

Notes from the Working Group meeting:

18:33 sadym: feature requested by users is setting network conditions. Started with offline mode. Technically can be done with Network Interception. Will be difficult to specify bandwidth etc.
18:34 sadym: talking about offline: several aspects : network requests and navigator online. With network interception we cannot influence navigator online, bur we can handle requests
18:35 sadym: currently navigator online is defined in a way which should return false if the user can't reach the network. Unclear behavior
18:36 sadym: proposal is to add a hook is offline so that the html spec can call this to know what to return
18:36 q+
18:36 * Zakim sees jdescottes on the speaker queue
18:36 ack jdescottes
18:36 * Zakim sees no one on the speaker queue
18:37 jdescottes: hook for html spec sounds good to me, especially since we can't block all network for now
18:38 q+
18:38 * Zakim sees jimevans on the speaker queue
18:38 sadym: should we split or land everything in one PR
18:40 jimevans: can be more work, but I would prefer to see the full implementation landed at once. I would expect everything to behave as offline/online when setting this emulation.
18:40 sadym: sounds good

[sadym-chromium]

@juliandescottes @OrKoN could you please take another look?

[sadym-chromium]

@juliandescottes PTAL

[juliandescottes]

Thanks for the update, and sorry for the delay. Overall I think the update for BiDi looks good, but I'm not sure how we should treat this PR since we have a dependency on HTML and Fetch.

I prefer to let James or other people more used to the spec world comment on this, my feeling is that we might need at least some agreement on the other PRs that they are ok with the direction. We can also discuss it next wednesday during the meeting.

[jgraham]

Apparently I made some comments a while ago and didn't submit them…

[jgraham]

Is this right? It's going to send a close frame to the server, which wouldn't happen if the browser was actually offline. Do browsers' existing offline modes actually send this frame when activated on a page with an open websocket?

[sadym-chromium]

Switched to Fail the WebSocket connection

[jgraham]

For now the check for type can just be an assert. I see you're trying to define this for extensibility although it does make the API rather odd in the short term, and the obvious extensions into network conditions seem like they're going to be rather challenging to standardise. I wonder if we'd be better with just a network.setOffline({contexts, userContexts, offline: <bool>}) command for now.

[sadym-chromium]

If we don't plan to extend for other network conditions (e.g. high-latency or low-bandwidth), I'd propose to:

1. Move the method to emulation.setNetworkOffline, as it influences not only the network, but the navigator as well.
2. Allow for only offline: true / null, as we cannot emulate being online when offline, we can only restore the default behavior.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed emulation.setNetworkConditions:offline.

The full IRC log of that discussion

<tidoust> Topic: emulation.setNetworkConditions:offline
<tidoust> github: https://github.com//pull/948
<jgraham> q+
<tidoust> sadym: Current version of spec is that no network emulation is pretty much airplane mode.
<jgraham> ack next
<tidoust> jgraham: I was definitely imagining something like "what if the network goes down at this point", rather than a clean network disconnection.
<orkon> q+
<tidoust> ... What happens if you engage offline mode. What does the prior art look like? Closing connections gracefully? Or shutting them down?
<sadym> q+
<jgraham> ack next
<jdescottes> q+
<tidoust> orkon: We discussed this. If you go offline, usually it's not instant, you have timeouts on HTTP, TCP, etc. navigator.online does not report the status right away.
<tidoust> ... What we discussed is that switching would only apply to new requests.
<tidoust> ... This is a simpler model, and I don't see a strong use case for airplane mode where you emulate offline mode.
<tidoust> ... You want to check that, e.g., your service worker picks up things correctly.
<tidoust> ... It would be difficult to emulate the real circumstances for when you're going offline given the many ongoing connections that may be happening.
<jgraham> ack next
<tidoust> sadym: Emulate tunnel in the train vs. airplane is what we need to get consensus on, then.
<jgraham> q+
<jgraham> ack next
<tidoust> jdescottes: The situation in Firefox is that there are two ways to get offline.
<tidoust> ... Two inconsistent features, including one in dev tools.
<tidoust> ... I still think that we should do more than preventing next request. Just failing requests on beforeRequestSent is not enough.
<tidoust> ... Some applications may be relying on other signals to switch to offline mode.
<tidoust> ... Also, this PR depends on two other PRs, do we want to wait until these two PRs are reviewed?
<jgraham> ack next
<sadym> q+
<tidoust> jgraham: In most testing scenarios, I agree that simplifying things is probably enough.
<tidoust> ... I believe the current PR covers the needs.
<tidoust> ... In the context of the scripting API, we've sometimes landed updates even when the background is broken when there are inter-dependencies. Sometimes, we need to go back and clean up the other PRs.
<sadym> q+
<tidoust> Blaze: Webkit uses this online/offline marker to switch mode.
<tidoust> ... That should align well with this.
<jgraham> ack next
<tidoust> ... I don't see any blocker.

[sadym-chromium]

@jgraham could you please take another look?