file download not working in electron

[BillCarterNet]

Current behavior

This appears to be the same issue as described in
#14747

However I am getting it in cypress 8.6.0

It eventually bombs out with

Error: ERR_FAILED (-2) loading 'https://docs.google.com/uc?export=download&id=1qnZDkUKzYKcgsrQlflMYtiQL5U1rmP_h'
    at rejectAndCleanup (electron/js2c/browser_init.js:161:7486)
    at Object.stopLoadingListener (electron/js2c/browser_init.js:161:7861)
    at Object.emit (events.js:376:20)
{
  errno: -2,
  code: 'ERR_FAILED',
  url: 'https://docs.google.com/uc?export=download&id=1qnZDkUKzYKcgsrQlflMYtiQL5U1rmP_h'
}
Error: ERR_FAILED (-2) loading 'https://docs.google.com/uc?export=download&id=1qnZDkUKzYKcgsrQlflMYtiQL5U1rmP_h'
    at rejectAndCleanup (electron/js2c/browser_init.js:161:7486)
    at Object.stopLoadingListener (electron/js2c/browser_init.js:161:7861)
    at Object.emit (events.js:376:20)

And returns you to the command line my downloads folder is empty

I ran into the same problem when trying to write a test in my automation framework at work and thought it might be a problem with the app (or proxy) but this seems to indicate otherwise.

Am I doing something wrong here?

Desired behavior

Allow me to download the file

Test code to reproduce

To reproduce:

1. Create a new NPM project
2. Install Cypress
3. Create a spec file as follows

describe('test', () => {
    it('downloads', () => {
        cy.visit('https://www.appsloveworld.com/sample-excel-data-for-analysis/')
        cy.get('.Downloadbutton')
        .eq(0)
        .click();
    });
});

4. Run the spec file in the runner

Cypress Version

8.6.0

Other

No response

[BillCarterNet]

Should I expect a response?

[ayzu]

I also experience the same issue with Cypress 9.0.0

[BlueWinds]

Thanks for your patience - we get a lot of issues opened and sometimes they slip through the cracks. I'm able to reproduce the issue exactly as described, an electron crash in 9.0.0. When run in Firefox, the download link opens in a new window.

Cypress tests are currently limited to a single top level domain, and your download link is pointing to google docs. https://docs.cypress.io/guides/guides/web-security#Same-superdomain-per-test has some more details on this limitation.

That's not to say this isn't a bug - Cypress crashing is never what we want to see! We're currently working on improving multi-domain support within Cypress, but for now you'll have to work around it by staying within the same top-level domain.

[ayzu]

Thanks for your patience - we get a lot of issues opened and sometimes they slip through the cracks. I'm able to reproduce the issue exactly as described, an electron crash in 9.0.0. When run in Firefox, the download link opens in a new window.

Cypress tests are currently limited to a single top level domain, and your download link is pointing to google docs. https://docs.cypress.io/guides/guides/web-security#Same-superdomain-per-test has some more details on this limitation.

That's not to say this isn't a bug - Cypress crashing is never what we want to see! We're currently working on improving multi-domain support within Cypress, but for now you'll have to work around it by staying within the same top-level domain.

Hey @BlueWinds

Thank you for the reply!

Could you please have a look at the similar issue? The difference is that I am using the same domain for the download link.

[BillCarterNet]

Thanks for the response @BlueWinds
My reproduction does mimic the app I am testing with Cypress, where we have links to file downloads on a different domain.
I want to download these generated files and check their content.
I'm not sure there is any work around for me, short of getting the app changed to fit in with Cypress's same single superdomain limitation.

Is this ever likely to change?
Perhaps we could give Cypress a list of other domains we consider safe or similar?

[BlueWinds]

Let me send a couple of links your way, and see if any of these help. The big takeaway is that when testing this sort of thing, usually clicking through isn't actually necessary - you can assert that the url on the link is correct, which gives you almost as much coverage.

https://docs.cypress.io/guides/references/trade-offs#Same-origin
https://docs.cypress.io/guides/references/best-practices#Visiting-external-sites
https://docs.cypress.io/guides/guides/web-security#JavaScript-Redirects
https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/server-communication__visit-2nd-domain

We are also working on direct multi-domain support, but it's likely to be several months before anything concrete is ready. #17336

[BillCarterNet]

Thanks @BlueWinds but as I said the app I'm testing generates these files and I need to download them and check (and write various asserts on) their contents.
Checking there is a correctly formed link to download them is not really enough coverage for the test I'm trying to write.
I read something somewhere about encasing puppeteer scripts as cypress commands to get around the domain limitations, I may dabble with this in the mean time.
Cypress is generally great, allowing multi-domain support would be a big plus!
Fix the element detached from the DOM problem too and I would be very happy with it.
Cheers!

[archfz]

The alternative proposed is far from ideal, as it only covers simple cases. In my case the URL is generated dynamically on JS side for the download file. I cannot assert on anything unless I click the button, which in turn breaks cypress or hangs it on 10.10.0

[flotwig]

It does seem like there is a bug here. When we are doing the win.loadURL for the child BrowserWindow, we aren't catching exceptions, and so loading a broken URL just crashes Cypress. Need more investigation on what to do here, but that does seem like the likely culprit. Possibly it's not just broken URLs, but any URL that causes an immediate file download.

We have a reproduction from #24354 in this repo: https://github.com/aaron-qa/cy-error-repoduce

[uhop]

I am getting seemingly the same problem:

Trace: The new-window event is deprecated and will be removed. Please use contents.setWindowOpenHandler() instead.
    at Object.log (node:electron/js2c/browser_init:225:603)
    at emitDeprecatedNewWindowEvent (node:electron/js2c/browser_init:185:1303)
    at openGuestWindow (node:electron/js2c/browser_init:185:1685)
    at EventEmitter.<anonymous> (node:electron/js2c/browser_init:165:14118)
    at EventEmitter.emit (node:events:527:28)
ERR_FAILED (-2) loading 'about:blank#blocked'
Error: ERR_FAILED (-2) loading 'about:blank#blocked'
    at rejectAndCleanup (node:electron/js2c/browser_init:165:7500)
    at EventEmitter.stopLoadingListener (node:electron/js2c/browser_init:165:7875)
    at EventEmitter.emit (node:events:527:28)

And it stops going over the rest of tests. We are debugging our own web app deployed to a public URL. Our code does not use new-window anywhere nor opens about:blank nor about:blank#blocked. All test steps can be repeated manually without problems.

The versions:

Cypress:        12.0.2
Browser:        Electron 106 (headless)
Node Version:   v14.21.2 (/Users/eugene/.nvm/versions/node/v14.21.2/bin/node)

[elyhouadria]

I have the same issue downloading a PDF in a new tab crashes Electron. As a result it is impossible to run these kind of tests in CI. This issue doesn't happen with other browsers.

[aaron-qa]

@flotwig any idea when this can get fixed?

Looks like I'm going to have to switch to Firefox as the latest version of Chrome isn't performing well with the Cypress version I'm sticking with to avoid this issue.

[AyeshW]

I am getting the same issue in Cypress 12.14.0

Cypress:        12.14.0                                                                        │
Browser:        Electron 106 (headless)                                                        │
Node Version:   v16.0.0

[JamesBug404]

I am trying to use chrome but the same issues. any fix please?

[stepanroznik]

The bug is still present in Cypress 13.3.3

Cypress:              13.3.3 
Browser:              Electron 114 (headless) 
Node Version:         v18.12.1