testcafe
testcafe copied to clipboard
Using Firefox with screenshots and videos activated may hang TestCafe on a test failure
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
takeScreenshotandgetVideoFrameDatafunctions called thegetScreenshotDataalmost at the same time and then "intercepted" each other's responses, and execution hanged (probably in one of the while loops in the_getPacketfirefox/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?
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_getResponsefn 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.jsfile, go to thetakeScreenshotfn and add a logconsole.log(`[TMP][${Date.now()}] takeScreenshot - before getScreenshotData`)before theawait browserClient.getScreenshotData - Open the
node_modules/testcafe/lib/browser/provider/built-in/dedicated/firefox/index.jsfile, go to thegetVideoFrameDatafn and add a logconsole.log(`[TMP][${Date.now()}] getVideoFrameData - before getScreenshotData`)beforereturn marionetteClient.getScreenshotData()
- Open
- 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
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.
@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.
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.
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.
This issue has been automatically marked as stale because it has not had any activity for a long period. It will be closed and archived if no further activity occurs. However, we may return to this issue in the future. If it still affects you or you have any additional information regarding it, please leave a comment and we will keep it open.
We're closing this issue after a prolonged period of inactivity. If it still affects you, please add a comment to this issue with up-to-date information. Thank you.