Cypress tests hang waiting on user to interact with download dialog

[josephong]

Sorry if this is addressed in the documentation – I couldn't find anything on it. When I run a spec, programmatically clicking on a link that downloads a file triggers a download dialog. However, in order to make the test progress, I have to manually dismiss the dialog.

Is there an option that will close download dialogs automatically?

[brian-mann]

Nope this requires native events, which have not been implemented in Cypress.

There is an issue open #311 but I haven't written the explanation for it. It's orthogonal to #310 though which can give you some perspective.

Currently as a workaround just:

• don't click the link
• bind to the event which triggers the dialog (in Cypress) and call e.preventDefault() on it

[bahmutov]

if the test e.preventDefault() on the button, for example, it would just disable the button's action we need and trying to test, right?

[brian-mann]

Okay what you should do is isolate the method that ends up making the HTTP request which sends the disposition headers which caused the file prompt to appear.

Then just use cy.stub to stub out that method and make sure its invoked with the right arguments. Then the thing creating the side effect is isolated and well tested without it doing anything.

You'll need this globally exposed somehow, either attached to some global App object, or perhaps just in test mode expose the function itself. Few different ways to solve this.

[brian-mann]

Here's some examples of what I'm referring to:

https://github.com/cypress-io/cypress-example-recipes/blob/593451b6d66c5100e4efb9ac861d9ff8e2f784b7/cypress/integration/logging_in_xhr_web_form_spec.js#L103

https://github.com/cypress-io/cypress-example-recipes/blob/master/cypress/integration/spy_stub_clock_spec.js

[kutlaykural]

Hi @brian-mann
I am triying to stub a request which has disposition headers.
Is there any difference between "XHR and Fetch" request and Doc for Cypress

[brian-mann]

Just use cy.request to programmatically make the request that would send the right headers to download the file and assert on the headers. That's all you need to do to know that the browser would have downloaded the file.

Alternatively you could set some flags in chrome to force it to accept downloads to a default location and then just assert that the file is present on the file system.

[tnrich]

@brian-mann could you explain more about

set some flags in chrome to force it to accept downloads to a default location and then just assert that the file is present on the file system.

How exactly would one do that in their cypress run command?

Thanks!

[jennifer-shehane]

@tnrich There is an example of setting chrome flags here.

[tnrich]

@jennifer-shehane hmm interesting, I looked briefly but didn't see a flag for auto-accepting downloads. Do you see one?

[jennifer-shehane]

No, I was unable to find an appropriate Chrome flag either. @brian-mann you remember which flag you were suggesting?

set some flags in chrome to force it to accept downloads to a default location and then just assert that the file is present on the file system.

[rajfnu]

@jennifer-shehane wondering if you find the chrome flag

[lorensr]

This workaround prevents Chrome from trying to download the file:

    cy.server();
    cy.route({
      url: '/foo',
      status: 304,
      response: '',
    }).as('foo');

[harunhasdal]

Chrome preferences to avoid the download popup are;

{
  'download.default_directory': <full path to a download directory>,
  'profile.default_content_settings.popups': 0
};

However I'm not sure if cypress cli allows setting these.

[jennifer-shehane]

@harunhasdal This API comes from Selenium. I don't think there's a way to do this through Cypress currently. I may be wrong, but I think we need to extend Cypress to create an API for these prefs to be passed in - then we pass them onto the Chromium profile.

Chromium code using prefs: https://chromium.googlesource.com/chromium/src/+/master/chrome/common/pref_names.cc#1427

[harunhasdal]

@jennifer-shehane thanks for the link, the correct chromium preferences seem to be instead of the selenium ones mentioned above.

download.default_directory
download.prompt_for_download

I believe, it would be a very useful to be able to configure chromium with a Cypress API. Not only limited to this issue.

[jennifer-shehane]

@harunhasdal Can you open a new issue to ask for specifying Chromium preferences in Cypress? There isn't an issue open for this yet.

[Chase817]

@jennifer-shehane Is there any workaround to disable the save prompt when automating downloads in headless Electron?

[jennifer-shehane]

@Chase817 I'm not aware of a workaround.

[kamituel]

@Chase817 Two of the approaches we're using in our tests are described here: #949 (comment)

Those don't prevent Electron from showing the "save" prompt per se, but instead work around in a way that no file has to actually be downloaded (and yet you get file contents to assert on).

[jennifer-shehane]

Closing as duplicate of #949

[jennifer-shehane]

File download is now supported in Cypress 6.3.0.

You can now test file downloads in Cypress without the download prompt displaying. Any files downloaded while testing file downloads will be stored in the downloadsFolder which is set to cypress/downloads by default. The downloadsFolder will be deleted before each run unless trashAssetsBeforeRuns is set to false.

This means that if you had any code written to prevent the download prompt or to configure the download location (like in a before:browser:launch event handler), you can remove all of these workarounds.

Our file download recipe has been updated, so you can see some ways to test different types of files after they've been downloaded there.

If you're encountering any bugs while testing file downloads, please open a new issue.