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]

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.

[sadym-chromium]

Actually, I believe that it still makes sense to keep it extendable and eventually introduce other conditions.

[jgraham]

Personally, I still feel like a separate command would have been the better design for now. The only advantage I see of a single command is that it will make it easier in the future to switch atomically from a "network offline" state to an online state with some other configuration. But that would be possible either way (e.g. by allowing the configuration to be set when offline, and applying it when online).

This would have the advantage of not making the existing protocol more complex in service of uncertain future requirements.

However since there is already general agreement about the approach here I don't consider it a blocker.

[sadym-chromium]

Ack, thanks for the clarification! I imagine we can extend the emulated conditions with some vendor-specific types in the nearest future until the proper specification is landed.

[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?

[sadym-chromium]

@juliandescottes @jgraham friendly ping

[juliandescottes]

Thanks Maksim, looks fine to me, just a couple of questions.

[juliandescottes]

Should we store the conditions on the session or on the remote end?
With the per session approach, the first session to be checked always wins. Whereas if it's per remote end, the last condition set wins, which feels easier to manage for users than (arbitrary) session order?

[sadym-chromium]

I don't have a strong opinion here, as currently we don't support multiple sessions. For now I changed the spec, so that we check all sessions' navigables, then user contexts, and then default settings.

[juliandescottes]

note: probably not important as long as we can only disable, but I'm wondering about scenarios where later we could support other network conditions eg throttling.

If navigable 1 is throttled and navigable 2 is offline, what should we do? We should probably defer that discussion to whenever we implement more conditions, but still curious if you have any thoughts about this.

[sadym-chromium]

note: probably not important as long as we can only disable, but I'm wondering about scenarios where later we could support other network conditions eg throttling.

If navigable 1 is throttled and navigable 2 is offline, what should we do? We should probably defer that discussion to whenever we implement more conditions, but still curious if you have any thoughts about this.

This spec version defines the behavior as "the first created navigable wins". This scenario happens for shared workers. However IDK what exactly Chromium does in this case, and I don't have a strong opinion what it should do.

[whimboo]

@sadym-chromium Will you also work on the wpt tests whenever you are going to work on supporting this feature?

[sadym-chromium]

@sadym-chromium Will you also work on the wpt tests whenever you are going to work on supporting this feature?

The wpr tests are landed

[whimboo]

Ah, there was no link to web-platform-tests/wpt#55300 in this PR. Thanks!