Download file works in chromium but fails with chromium:headless (linux)

[TauPan]

What is your Test Scenario?

Downloading a file from a website (any, really) to ${process.env.HOME}/Downloads and checking the contents.

What is the Current behavior?

Download works with chromium gui on linux, but fails with chromium:headless. Screenshot after clicking the download link show just the download page but no statusbar with download in progress. The loop waiting for the file to be complete takes forever, there is no file in ${process.env.HOME}/Downloads.

What is the Expected behavior?

File is downloaded. Additionally, I'd expect tests to behave identically in headles or GUI mode.

What is your web application and your TestCafe test code?

My full code is at https://github.com/TauPan/Tageblatt-Downloader however the download would only work with my login data. I assume that the problem can be reproduced with any site offering a download.

Steps to Reproduce:

Your Environment details:

• testcafe version: 0.23.2
• node.js version: v8.9.4
• command-line arguments: testcafe chromium:headless --hostname localhost --skip-js-errors --screenshots screenshots --screenshots-on-fails test/test_*
• browser name and version: Chromium Version 70.0.3538.102 (openSUSE Build) (64-Bit)
• platform and version: openSUSE Leap 42.3
• other: This seems relevant https://bugs.chromium.org/p/chromium/issues/detail?id=696481#c141

Maybe it can be fixed with a configuration.

[TauPan]

My full code is at https://github.com/TauPan/Tageblatt-Downloader however the download would only work with my login data. I assume that the problem can be reproduced with any site offering a download.

[AlexKamaev]

Sorry for the delay. I researched the issue and found that downloading in headless mode could be implemented via Chrome Debug Protocol.

Please refer to the following links to get started:
Chrome DevTools Protocol
chrome-remote-interface package
chrome-remote-interface repo

I've prepared the following workaround:

const path = require('path');
const CDP = require('chrome-remote-interface');

import { Selector } from 'testcafe';

fixture `test`
    .page `https://github.com/DevExpress/testcafe/`;

test('test', async t => {

    const client            = await CDP();
    const { Network, Page } = client;

    await Promise.all([
        Network.enable(),
        Page.enable()
    ]);

    Network.requestWillBeSent((param) => {
        console.log("Network.requestWillBeSent: " + JSON.stringify(param));
    });

    Network.responseReceived((param) => {
        console.log("Network.responseReceived: " + JSON.stringify(param));
    });

    await Page.setDownloadBehavior({
        behavior: 'allow',
        downloadPath: path.resolve(__dirname, 'downloaded')
    });

    await t.click(Selector('summary').withText('Clone or download'));
    await t.click(Selector('a').withText('Download ZIP'));

    await t.wait(20000) // please replace with string with your function which detects that the file exists
})

This test navigates to the TestCafe repository and downloads the .zip archive. You should use the following command to start the test: node bin/testcafe "chrome:headless:cdpPort=9222" test.js. Here I define the cdp port that is used by the CDP module by default.
Note that it is hard to predict what unexpected results this workaround can produce, and I suggest that you carefully check this prior to integrating this solution into your project.

We will consider integrating this feature to TestCafe.

[dlangerenken]

While this works great for chrome:headless - is there anything similar for firefox:headless? @AlexKamaev

[dlangerenken]

Quick note (see #3600 for more information): If you specify the cdpPort manually, you should not run in concurrent-mode since this will lead to errors. So while this workaround allows you to download files, it will not allow you to run concurrently

[AlexKamaev]

I've modified my example a little. Now it will allow you to use the concurrency option. Please refer to https://gist.github.com/AlexKamaev/8c1eb8a5fb638fa366b44447f6d7c5a4
This example is using an internal TestCafe API. It works stable, however, it can change in the future

[lock]

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.