emulation.setNetworkConditions

[sadym-chromium]

Addressing #776

Implement offline emulation.

Out of scope: HTML navigator.onLine.

---

Preview | Diff

[juliandescottes]

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

[juliandescottes]

What is the added value of an offline emulation which only rejects on beforeRequestSent. It seems you can easily implement this with addIntercept + failRequest? Even if we ignore navigator.online, an offline mode should impact ongoing requests, websockets, allow you to test service workers etc... I feel like a limited feature like this would be more confusing than anything else?

[OrKoN]

I was under impression that this was discussed in the WG? I do not think the offline mode should apply to ongoing requests and with this it should apply to web sockets and service worker requests as they have to start via fetch? The advantage is that you do no pay the cost of interception and have a dedicated command that can be extended with further aspects specific to the network condition emulation. The question I would have if this allows successfully testing the offline mode behavior of the browser which is probably a bit more than failing the network requests?

[juliandescottes]

I was under impression that this was discussed in the WG?

I thought so as well, but I wanted to check the details and I can't find any summary for this discussion. So I'm just giving my feedback based on what is currently proposed. I couldn't find a matching topic in the last 6 meetings, but maybe this was discussed informally?

For service workers, I would need to check in details. I was thinking about a fetch request which gets captured by an already registered service worker, returning a response from the cache. This should still work in offline mode, but not sure that's the case here?

For websocket, is fetch used for anything but establishing the connection at https://websockets.spec.whatwg.org/#concept-websocket-establish ? I was thinking about ws messages on an already open websocket.

The question I would have if this allows successfully testing the offline mode behavior of the browser which is probably a bit more than failing the network requests?

I think the answer to this is no, but I don't know if the offline mode is completely specified.

But if the WG agreed to have something that only blocks new fetch requests as an offline mode, I don't mean to block the PR (would be great if I could find the discussion though :) )

[OrKoN]

I was not attending unfortunately so I do not know for sure :)

[jgraham]

I don't remember such a discussion and broadly agree with Julian's concerns here; I'd certainly expect that in offline mode navigatior.onLine should be false, and for the offline event to fire when the state changes. I also agree it would be extremely surprising if e.g. open websockets (or server sent events eventsources) continue to work in "offline" mode.