cypress
cypress copied to clipboard
cypress-io
Simulate offline mode
Description Offline support is becoming important to web applications. It would be nice to switch the browser to the offline mode from Cypress either by test or for all tests and run it. If might be difficult and might require Cypress to handle ServiceWorkers very well.
Additional Info
This should be possible to do, but it's not immediately obvious or easy.
Thoughts / Concerns
- To date we haven't built in any specific API's that only work with one browser vendor. I'd like to try to find another way to do this, perhaps at OS network or proxy level since we control those two things.
- Chrome supports this out of the box in the
debuggerprotocol but attempting to use that puts us in the same situation as issuingnative events- that is you cannot have theDev Toolsopen and an open connection to thedebuggerprotocol. Chromium team is working on multiplexing support so we're kind of waiting for that to drop before adding support. - If we did write API's exclusive to a single browser vendor, would they automatically throw (or be ignored) when running on a different browser? We'd also need a way at the
testorsuitelevel to indicate you want to inclusively or exclusively run tests based on the current browser. - If we did use Chrome's APIs to achieve this, it would essentially break Cypress's ability to do automation since
websocketevents would no longer be able to reach the server. So if we did tap into Chrome we could only partially throttle and not fully force into offline mode. Another option would be to use theWebRequestAPI's and whitelist Cypress network traffic but throttle or reject others.
I'll move this into our Roadmap for further research.
With Chrome 63 coming out we will be able to support the debugger protocol. #832
Is there any progress/news on this? Would be cool to be able to test PWAs 👍
I am using Redux and we store the online/offline status of the browser there. So what we did was to expose the Redux store like this in eg index.js (only works on localhost):
if (window.Cypress) {
window.store = store
}
Then in a test in cypress we dispatched an action to set the Redux state to be offline:
cy.window().its('store')
.then(
store => store.dispatch({type: 'OFFLINE', status: true})
);
Related issue for clearing ServiceWorkers: https://github.com/cypress-io/cypress/issues/702
@lolpez We prioritize issues we work on based on a variety of factors - including the number of users requesting/helped by a feature. While this is still on our Roadmap, many other features are a higher priority today as a result of this assessment. Sorry for the delay.
I tried to simulate offline by setting up a reverse proxy to my running server and then shutting it down.
const httpProxy = require("http-proxy");
context("Offline", () => {
before(() => {
httpProxy.createProxyServer({ target: "http://localhost:9000" }).listen(9001);
cy.log("Open / on proxy");
cy.visit("http://localhost:9001/");
});
it("should show update notification", () => {
// wait for initial service worker installation
cy.wait(3000);
// stop the proxy server
proxy.close();
// reload the page
cy.reload();
});
});
But I get a http.createServer is not a function error.
If I run just these two files in a separate file there is no problem
const httpProxy = require("http-proxy");
httpProxy.createProxyServer({ target: "http://localhost:9000" }).listen(9001);
Is this a known limitation / problem?
It would be really good to have this feature.
I can currently set the offline state in our vuex store but when changing pages (ie cy.visit) the application rechecks the state and updates the store value and is flushing queues before I get a chance to set the store again!
Absence of this feature actually forces us to use selenium with direct access to driver api so we can test our core functionality in offline mode as our use case is offline-first.
I hope you will find time soon for this.
The project my team is working on requires that we are able to simulate a No Internet Connection environment as well.
Please provide an update on this!
This issue is still in the 'proposal' stage, which means no work has been done on this issue as of today, so we do not have an estimate on when this will be delivered.
One way of simulating offline mode:
cy.server({ force404: true }); // offline mode
cy.server({ enable: false}); // online mode
https://docs.cypress.io/api/commands/server.html
One way of simulating offline mode:
cy.server({ force404: true }); // offline mode cy.server({ enable: false}); // online modehttps://docs.cypress.io/api/commands/server.html
that only blocks the calls, it doesn't tell the browser there's no internet
that only blocks the calls, it doesn't tell the browser there's no internet
Yes, it doesn't tell the browser that there is no internet, but by preventing the requests, we can test the offline functionality of PWA. It's just a workaround.
In my case it doesn't help, it should appear a "offline" banner and it doesn't. Thanks anyway
The root of the app is not cachable because of the MITM that Cypress performs (`document.domain = 'localhost').
This would make it (at least to me) that one would enable offline-mode after having started testing. First you'd want to install your service worker and such, adding all required files to the cache, and then run some tests. This would mean a global option is not required/desired - if you have no cache, no prior visits to the site - offline will never work anyways.
Design
// Quick and dirty
cy.offline()
// - do tests inbetween
cy.online()
// A probably better way:
cy.network({offline: true})
// - do tests inbetween
cy.network({offline: false])
The latter would enable Cypress to at at later point also add throttling in the options. Not sure as to the usefulness of throttling, but that's point of discussion for another issue.
Docs
The Chrome Debugger (Chrome, Electron) allows for the following, but Firefox does not.
Cypress.automation('remote:debugger:protocol', {
command: 'Network.enable',
})
Cypress.automation('remote:debugger:protocol', {
command: 'Network.emulateNetworkConditions',
params: {
offline: options.offline,
'latency': 0,
'downloadThroughput': 0,
'uploadThroughput': 0,
'connectionType': 'none',
},
})
Hurdles
@brian-mann wrote: If we did use Chrome's APIs to achieve this, it would essentially break Cypress's ability to do automation since websocket events would no longer be able to reach the server. So if we did tap into Chrome we could only partially throttle and not fully force into offline mode. Another option would be to use the WebRequest API's and whitelist Cypress network traffic but throttle or reject others.
Half-way through my test (within a single it), I was able to enable offline-mode without any problems (manually, that is). After the tasks have been queued at the start, there should not be any issues with that.
Update
I've created a PR, but I'm not making any progress on Firefox.
According to this issue Firefox does not seem to implement Network.emulateNetworkConditions yet - and I haven't found a suitable replacement either. For some reason, those APIs don't have easily accessible documentation.
The Firefox UI has a Work offline mode, which does the same - I just haven't found a way to automate this.
Update 2
Unless we figure out how to automate it for Firefox, the chances of any PR making it into Cypress are slim to none.
Call to everyone: feel free to try and find a way ;-).
Update 3
Work on the Network.emulateNetworkConditions CDP command in Firefox has started. All seems to be going well, except that Firefox - as of writing- , allows access to everything that resolves to localhost even in Work Offline-mode. This is still being figured out to make automated testing a bit more useful.
@EtienneBruines Any chance this could take a staged approach with chromium based support first? There are already other examples in the docs of features/workarounds that are only available in chrome, and some coverage is better than none.
@rpocase if there is enough demand for it, I guess it could.
As mentioned in #6932 we could publish it as a separate npm package (open source, so feel free, even if I don't end up doing so). The Cypress team has expressed (rightfully so) to not want this 'half-baked', so either full support in all by-Cypress-supported-browsers, or as a separate npm package that people can use at own risk.
Today we submitted a PR to https://bugzilla.mozilla.org/show_bug.cgi?id=1553849 to enable Network.emulateNetworkConditions on Firefox as well. The people working there really were an awesome help in getting it this far.
I can't speak on behalf of Cypress (just an outsider here :sweat_smile: ), but I'm guessing that once Firefox support lands (hopefully Firefox 78.xxxx, but I don't know for sure), and I add those tests to #6932 - they'd be up to including it.
Today we submitted a PR to bugzilla.mozilla.org/show_bug.cgi?id=1553849 to enable
Network.emulateNetworkConditionson Firefox as well. The people working there really were an awesome help in getting it this far.
@EtienneBruines awesome! we have been closely monitoring Firefox team's progress on the CDP implementation, we are excited to use it in Cypress
I can't speak on behalf of Cypress (just an outsider here sweat_smile ), but I'm guessing that once Firefox support lands (hopefully
Firefox 77.xxxx, but I don't know for sure), and I add those tests to #6932 - they'd be up to including it.
~~I believe CDP support is still only available in Firefox Nightly releases, so we can't really use any of it until they make it available in all editions of Firefox.~~ Never mind, just learned that CDP support is in all editions, so this may be possible if it makes it to stable. Perhaps we'll also be able to switch some of our other automation code over to using CDP at the same time.
Quick update:
-
Network.emulateNetworkConditionshas landed in Firefox 78.0a1 nightly (around 4:00 UTC this morning) :tada: - Firefox always allows requests to
localhost, as well as anything that resolves to it - even in offline mode (no patch in progress yet) - I've managed to enable CDP for Firefox in Cypress, but this required two more changes:
-
Browser.getVersionupdate in Firefox (patch added and landed in 78.0a1) -
Network.getAllCookiessupport in Firefox (patch added, and accepted)
-
With all of the above patches in Firefox, I've managed to successfully implement cy.network on Firefox as well. Offline-only, so no throttling etc., but hey - that's all this issue is about.
Regarding Chrome there's still the issue of service-workers ignoring offline emulation, but for the past two weeks others have been working hard on Chrome to fix that issue as well - so I'm not worrying about that, that just means that service-worker support is only for newer Chrome versions. Seems like that Chrome-issue was fixed this month :tada:
Updated the PR with the progress - still lots of work to be done :sweat_smile:
@EtienneBruines is cy.network already available in the API? if yes, can u point me to the docs? haven't been able to find any info.
@jpita The underlying support for such a feature only just landed in Firefox Nightly, and Chrome is still working on some important bugfixes.
That said, the Pull-Request (that is, #6932) was updated - but the PR has not yet been merged into cypress/develop and is therefore also not (yet) a part of any Cypress release. Sorry for the confusion.
The cy.network I mentioned is the one hypothesized in https://github.com/cypress-io/cypress/issues/235#issuecomment-608367340
Offline-only, so no throttling etc., but hey - that's all this issue is about.
FYI, #4176 will implement offline mode as well as simulated throttling/latency at the HTTP proxy level, but it's still a ways off. So having "offline mode" accessible via a plugin that uses CDP to get the job done will still be valuable in the mean time.
@flotwig That's nice to know.
I'm just wondering, will #4176 affect the navigator.onLine representations, among others? Or is it a fancy way of turning the Cypress-Proxy off? (I don't know what the navigator.onLine value does when the proxy is offline.)
The CDP-Network.emulateNetworkConditions acts like an "airplane mode"-toggle, and therefore does influence that value (and fire the events that come with it) - useful for testing showing a message "You are currently offline" to the user.