'userDataDir option should restore state' test is flakily timing out for Firefox

[jschfflr]

Example run: https://github.com/puppeteer/puppeteer/pull/7614/checks?check_run_id=3745478501
@whimboo Do you know what might be causing this?

[whimboo]

Hard to say without seeing trace logs. But I would assume that Firefox had a problem during startup so that enabling the CDP protocol happened too late.

@jschfflr, would it be possible to set the webdriver.log.level=Trace preference for Firefox when it's running in CI? The log files will be larger but we find it very helpful when investigating intermittent failures like that.

[whimboo]

We actually have https://bugzilla.mozilla.org/show_bug.cgi?id=1713030 for that. So I would take a look over there.

[jschfflr]

Given that it's also happening on your side would it be possible to run the tracing version there and to disable the test on Puppeteer's CI for now?

[whimboo]

Yesterday I noticed a strange behavior when running Puppeteer with Firefox and having trace logging enabled. Whenever our CDP implementation logs something to stdout or stderr Firefox freezes because writing to these pipes is blocking (fputs never returns).

@jschfflr, given that Puppeteer uses both could it be that it's no longer processing the output once it has received the DevTools WebSocket URL for CDP? The situation on this issue is a bit different but it could be related. Locally it is kinda annoying because I'm not able to run Puppeteer with trace logs anymore. Maybe something has been changed here recently?

[jschfflr]

@whimboo Do you think this should be resolved with your recent pipe PR (#7644)

[whimboo]

Probably not, but it's towards the path of letting me run tests locally with custom builds. We will see how it goes once that PR got merged.

[whimboo]

The problem is that this test creates a temporary folder for the Firefox profile, but the default Firefox preferences aren't getting set. This means the profile isn't actually usable with Puppeteer. Chrome doesn't exhibit this problem because all settings are done via command line arguments.

@jschfflr extracting the profile location from the Firefox arguments inside the Launcher is not ideal and failure prone if eg no path has been set after --profile. Do you think that it would make sense to actually pass the profile folder through the launch options as userDataDir instead?

[whimboo]

My PR #7684 has been merged. I assume there is nothing else that we have to do here and can close this issue? CC @OrKoN.