Using Firefox with screenshots and videos activated may hang TestCafe on a test failure

[AlexZagriychuk]

What is your Scenario?

Run TestCafe tests on Firefox with screenshots, videos, retries (quarantineMode) activated.

What is the Current behavior?

Sometimes execution hangs on the test failure.

• When it hangs, it happens because both takeScreenshot and getVideoFrameData functions called the getScreenshotData almost at the same time and then "intercepted" each other's responses, and execution hanged (probably in one of the while loops in the _getPacket firefox/marionette-client).
  Logs (_logs_with_error.log):

[TMP][1739243838950] getVideoFrameData - before getScreenshotData
[TMP][1739243838952] takeScreenshot - before getScreenshotData
[TMP] _getResponse wrong packetNumber "502" (expected "501")
[TMP] _getResponse wrong packetNumber "501" (expected "502")

What is the Expected behavior?

TestCafe execution does not hang, test fails, and has screenshots and videos in the required folder

What is the public URL of the test page? (attach your complete example)

N/A

What is your TestCafe test code?

test-cafe-bug.zip updated

Your complete configuration file

In the attached archive

Your complete test report

In the attached archive

Screenshots

No response

Steps to Reproduce

• Download the attached archive with the simple TestCafe repo setup to reproduce this issue
• npm i
• (Optional) add a few "debug" logs which seem to have helped me pin point the issue
  • Open node_modules/testcafe/lib/browser/provider/built-in/dedicated/firefox/marionette-client/index.js, go to the _getResponse fn and replace the while loop with:

        while (!responsePacket.body || responsePacket.body[1] !== packetNumber) {
           console.log(`[TMP] _getResponse wrong packetNumber "${responsePacket.body[1]}" (expected "${packetNumber}")`)
           responsePacket = await this._getPacket();
           console.log(`[TMP] _getResponse wrong packetNumber - responsePacket for retry (packetNumber: "${responsePacket.body[1]}"):\n${JSON.stringify(responsePacket, null, 2)}`)
       }
  

  • Open the node_modules/testcafe/lib/browser/provider/built-in/dedicated/base.js file, go to the takeScreenshot fn and add a log console.log(`[TMP][${Date.now()}] takeScreenshot - before getScreenshotData`) before the await browserClient.getScreenshotData
  • Open the node_modules/testcafe/lib/browser/provider/built-in/dedicated/firefox/index.js file, go to the getVideoFrameData fn and add a log console.log(`[TMP][${Date.now()}] getVideoFrameData - before getScreenshotData`) before return marionetteClient.getScreenshotData()
• Run the test multiple times until the execution hangs (2-10 times) rm -rf artifacts; DEBUG=testcafe:* npx testcafe firefox:headless Tests/. --page-load-timeout 15000 --skip-js-errors > _logs.log 2>&1

TestCafe version

3.7.0

Node.js version

v22.2.0

Command-line arguments

firefox:headless Tests/. --page-load-timeout 15000 --skip-js-errors

Browser name(s) and version(s)

Mozilla Firefox 119.0.1

Platform(s) and version(s)

MacOS 15.0.1 (Sequoia)

Other

No response

[Bayheck]

Hello,

Your archive does not include config. Please update the archive.

In addition, please share the following information: OS and its version, Firefox version, and Node version.

[AlexZagriychuk]

@Bayheck Sorry, Mac treated it as a hidden file and have not included it into the original archive.
Uploaded the updated archive (https://github.com/user-attachments/files/18853204/test-cafe-bug.zip) and changed the link in the description as well. Also added the information with versions.

[AlexZagriychuk]

P.S. we've also noticed TestCafe + Firefox sometimes hanging (probably on failure) even if we only have screenshots + retries activated (no video). Could not reproduce it locally, but this happens rarely on CI. Might also be related to these while loops in the _getPacket fn in some rare corner cases turning into the endless loop, but not 100% sure.

[github-actions]

We appreciate you taking the time to share information about this issue. We reproduced the bug and added this ticket to our internal task queue. We'll update this thread once we have news.