-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't find profile directory #4660
Comments
The problem is with the profile directory passed to firefox ( |
@yury-s I can't find the profile directory in the app data folder. (Sorry if i didn't included that above) I can see a bunch of other It also worked a few times after i set |
@yury-s: We auto-create these folders for the execution and auto-delete them after, I don't think they pass any -profile. |
i am facing this issue when running multiple instances of firefox in parallel. running in serial does not cause an issue. so it might be that each time the next instance starts, it deletes the user profile of the previous one? if that is the case, shouldn't we create a folder per instance with different name? thanks! |
@devmondo could you please share the snippet to help me reproduce locally? |
@aslushnikov thanks for the support! unfortunately i cant share the private code, but it is nothing special really. import {firefox} from "playwright-firefox";
async function runBrowser(){
const browser = await firefox.launch();
await browser.newContext({
ignoreHTTPSErrors: true,
viewport: null,
});
}
await Promise.all[runBrowser(),runBrowser()];
please let me know if i could help more. thanks! |
@devmondo ah, two browsers simultaneously! Awesome, I can repro now! We'll fix it shortly |
Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References microsoft#4660
browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
This roll includes: - fix for Windows start - crashpad disabling - refreshed Firefox Beta @ Feb 19, 2021 Fixes microsoft#4660, fixes microsoft#4780
Context:
Code Snippet
Describe the bug
This is the logs from
DEBUG=pw:browser*
It used to work for me for some time. Had this exact error before. Solved it by reinstalling
playwright-firefox
setting ```process.env.PLAYWRIGHT_BROWSERS_PATH = "0";
The text was updated successfully, but these errors were encountered: