Cypress is not downloading files in the cypress/downloads folder on Firefox (Windows)

[laerteneto]

Current behavior

Even though I explicitly wrote "downloadsFolder": "cypress/downloads", on my cypress.json file, the files are not being downloaded inside this default folder when I am running my tests on Firefox locally in both headless and headed.

Desired behavior

The file should be downloaded inside the default folder, which is cypress/downloads (It is working normally on Chrome and Edge)

Test code to reproduce

Do it on Firefox (On Chrome based browsers it works):

• Create a test to click in some link/button that will download a file (In my case it is a CSV file)
• Observe the file is downloaded, but it is not being downloaded in the default cypress/downloads folder

Cypress Version

8.3.0

Other

• It was observed in both UI and CI mode on Windows 10 Pro edition.
• When I run it in my Bitbucket pipeline (with Linux machines) this issue is not found. Therefore, I believe it is a specific Windows issue with Firefox and so the file is not downloaded in the default cypress/downloads folder.

[laerteneto]

The issue still exists on Cypress 9.3.1 and Firefox 96

[deluxanmariathasan]

I'm facing the same issue while downloading the CSV file it downloads to users/download directory instead of cypress/downloads. Configured cypress.json with "downloadsFolder": "cypress/downloads"

[poponuts]

With the latest 9.3.1, I suddenly have this issue. Downloading gets stuck.

[artigat1]

I've started getting this issue with Windows 11. The tests are passing fine on the Linux build server, but all the file download tests are failing when I run them locally. I've installed 9.5.0 today and the same thing is happening.

[laerteneto]

Issue still detected, instead of downloading the file in the default cypress/downloads folder (as it does perfectly on Chrome/Edge), the file is download in the default Windows download folder.

Cypress version: 9.7.0 Firefox: 100 Windows: 10

[mirobo]

Workaround Cypress 9.7.0 on Windows (don't know how Mac behaves here):

  on('before:browser:launch', (browser, launchOptions) => {
    if (browser.name === 'firefox') {
      launchOptions.preferences['browser.download.dir'] = `${path
        .join(__dirname, `../../cypress/downloads`)
        .replaceAll('\\', '\\\\')}`;
    }
    return launchOptions;
  });

I also created a PR (pretty much blindly because Cypress development just does not work on my corporate notebook) for newer versions... there are no tests in Cypress checking this stuff.. hopefully someone from Cypress can write some.. to ensure future compatibility with newer Firefox versions. Not sure when it broke.. but the profile stores "browser.download.dir".. so if it has been successfully set once, it probably works also for newer versions. And only people recently trying out tests with Firefox ran into this issue..

[RadwaSaleh]

This issue still exists in: Cypress Version 10.4.0 Electron: 102 MacOS

and having downloadsFolder: 'cypress/downloads' set in cypress.config.js

[mirobo]

This issue still exists in: Cypress Version 10.4.0 Electron: 102 MacOS and having downloadsFolder: 'cypress/downloads' set in cypress.config.js

Could you please check if this workaround works on MacOS? It works for me on Windows (I have no Mac)

  const path = require('path');  / import path from 'path';
  ...
  on('before:browser:launch', (browser, launchOptions) => {
    if (browser.name === 'firefox') {
      launchOptions.preferences['browser.download.dir'] = `${path
        .join(__dirname, `your path`)
        .replaceAll('\\', '\\\\')}`;
    }
    return launchOptions;
  });

Maybe you need to replace the backslashes in "replaceAll" with the forward slashes?

Or when you started Firefox you just open a new tab in the browser instance that Cypress created and you open about:config to check the preferences. What I observed on Windows is that the preference was just not there. I needed to "double escape" the backslashes in order for the preference to appear like "C:\dev\whatever\cypress\downloads". Once it was double-escaped it worked on Windows.

@AtofStryker Unfortunately the current internal Cypress system-tests don't fail because they are not executed on Windows and MacOS. I found "windows-workflow-filters" in circle.yml but if I add my branch it will still not executed the system-tests (only launchpad tests and some other stufff). Not sure if all the prerequisites are fulfilled to run all system-tests against MacOS and Windows (and activate it also like "windows-workflow-filters"). I cannot test if my change with doubleEscape would work in MacOS :-(

Someone else needs to either verify my fix on MacOS or there needs to be a possibility to run system-tests on all 3 OS'es in CI somehow..

[AtofStryker]

OK I finally had some time to dig into #23006 and see what is going on.

@mirobo I was able to clone cypress and run the system tests in Windows 10 Home. I am guessing there might be some unique configuration to your machine that may be causing issues (maybe a CSP?), since you were able to get it to work on your laptop.

I was also able to run the system-tests for the downloads-spec and verified that the test does indeed fail without the fix, and passes with the fix with windows 10 home and firefox 103 as the installed browser.

It sounds like you discovered the windows-workflow-filter, which does run a subset of windows tests for verification of the binary and some chrome tests. It however, does not execute any firefox system tests on windows. The firefox system tests are only executed against Ubuntu to my knowledge (as you stated above).

We likely will not run the system tests against various OS providers due to cost factors. The OS, along with various browser versions, render the permutations of testing possibly endless with a high expense ratio. We believe the risk of unique regression to be relatively low, but obviously possible. Since a system-test already exists for this type of behavior, and will not be run in windows, I think the best mitigation step here to cover functionality would be to add a unit test in the firefox_spec inside the server to make sure the path is escaped properly. Since we are having some issues getting you running on your machine, would you like me to add the unit test? Or if your laptop setup is working would you like to add it? I'm happy with either 😃 !

I am also going to put this PR on the firewatch's team (support rotation) to get reviewed once we are ready. How does this sound?

[AtofStryker]

@RadwaSaleh I wasn't able to produce the issue on MacOS with Electron. Are you able to provide a reproduction?

[cypress-bot[bot]]

The code for this is done in cypress-io/cypress#23006, but has yet to be released. We'll update this issue and reference the changelog when it's released.

[cypress-bot[bot]]

Released in 10.6.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to Cypress v10.6.0, please open a new issue.