Skip to content
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

Closed
Nisthar opened this issue Dec 10, 2020 · 7 comments · Fixed by #5539
Closed

Can't find profile directory #4660

Nisthar opened this issue Dec 10, 2020 · 7 comments · Fixed by #5539
Assignees

Comments

@Nisthar
Copy link

Nisthar commented Dec 10, 2020

Context:

  • GOOD Playwright Version: same version (1.6.2)
  • BAD Playwright Version: same version
  • Operating System: Windows
  • Extra:

Code Snippet

process.env.PLAYWRIGHT_BROWSERS_PATH = "0";
process.env.DEBUG = "pw:browser*";
const { firefox } = require("playwright-firefox");
let page, browser;
export async function startAgent() {
  try {
    browser = await firefox.launch({
      headless: false,
      proxy: { server: "per-context" },
    });
 isStarted = true;
  } catch (e) {
    console.log(e);
  }
}
export async function work(proxy = false) {
  try {
    if (!isStarted) {
      await startAgent();
    }
    let context;
   context = await browser.newContext();
  page = await context.newPage();
 }
}

Describe the bug
This is the logs from DEBUG=pw:browser*

  �[30;1mpw:browser �[0m<launching> D:\node_projects\pwtest\node_modules\playwright-firefox\.local-browsers\firefox-1205\firefox\firefox.exe -no-remote -wait-for-browser -foreground -profile C:\Users\mypc\AppData\Local\Temp\playwright_firefoxdev_profile-vrPsOp -juggler-pipe -silent �[30m+0ms�[0m
  �[30;1mpw:browser �[0m<launched> pid=23116 �[30m+7ms�[0m
  �[30;1mpw:browser �[0m[out]  �[30m+1s�[0m
  �[30;1mpw:browser �[0m[out] Juggler listening to the pipe �[30m+1ms�[0m
  �[30;1mpw:browser �[0m[err] JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory. �[30m+662ms�[0m
  �[30;1mpw:browser �[0m<gracefully close start> �[30m+28s�[0m
  �[30;1mpw:browser �[0m<kill> �[30m+4ms�[0m
  �[30;1mpw:browser �[0m<process did exit: exitCode=1, signal=null> �[30m+288ms�[0m
  �[30;1mpw:browser �[0m<gracefully close end> �[30m+6ms�[0m
  �[30;1mpw:browser �[0m<launching> D:\node_projects\pwtest\node_modules\playwright-firefox\.local-browsers\firefox-1205\firefox\firefox.exe -no-remote -wait-for-browser -foreground -profile C:\Users\mypc\AppData\Local\Temp\playwright_firefoxdev_profile-92fLz0 -juggler-pipe -silent �[30m+717ms�[0m
  �[30;1mpw:browser �[0m<launched> pid=7208 �[30m+5ms�[0m
  �[30;1mpw:browser �[0m[out]  �[30m+1s�[0m
  �[30;1mpw:browser �[0m[out] Juggler listening to the pipe �[30m+1ms�[0m
  �[30;1mpw:browser �[0m[err] JavaScript error: resource://gre/modules/XULStore.jsm, line 66: Error: Can't find profile directory. �[30m+680ms�[0m
  �[30;1mpw:browser �[0m<gracefully close start> �[30m+27s�[0m
  �[30;1mpw:browser �[0m<kill> �[30m+3ms�[0m
  �[30;1mpw:browser �[0m<process did exit: exitCode=1, signal=null> �[30m+249ms�[0m
  �[30;1mpw:browser �[0m<gracefully close end> �[30m+4ms�[0m

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";

it worked for sometime. But its happening again.


@yury-s
Copy link
Member

yury-s commented Dec 10, 2020

The problem is with the profile directory passed to firefox (C:\Users\mypc\AppData\Local\Temp\playwright_firefoxdev_profile-*). Looks like it doesn't exist or there are permission issues, it might be that someone deletes it while playwright is running. I'd guess that it might also be free disk space issue on your C: drive. Can you check that the directory passed as -profile argument exists while playwright is still running?

@Nisthar
Copy link
Author

Nisthar commented Dec 12, 2020

@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 playwright_firefoxdev_profile-* folder but not the correct one. I have like 95gb free space on the drive. I understand why it works for a few time in the beginning and not now.

It also worked a few times after i set process.env.PLAYWRIGHT_BROWSERS_PATH = "0"; and its giving me the same error now.

@pavelfeldman
Copy link
Member

@yury-s: We auto-create these folders for the execution and auto-delete them after, I don't think they pass any -profile.

@devmondo
Copy link

devmondo commented Feb 3, 2021

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!

@aslushnikov
Copy link
Collaborator

i am facing this issue when running multiple instances of firefox in parallel.

@devmondo could you please share the snippet to help me reproduce locally?

@devmondo
Copy link

devmondo commented Feb 5, 2021

@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!

@aslushnikov
Copy link
Collaborator

@devmondo ah, two browsers simultaneously! Awesome, I can repro now! We'll fix it shortly

aslushnikov added a commit to aslushnikov/playwright that referenced this issue Feb 19, 2021
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
aslushnikov added a commit that referenced this issue Feb 19, 2021
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
aslushnikov added a commit to aslushnikov/playwright that referenced this issue Feb 20, 2021
This roll includes:
- fix for Windows start
- crashpad disabling
- refreshed Firefox Beta @ Feb 19, 2021

Fixes microsoft#4660, fixes microsoft#4780
aslushnikov added a commit that referenced this issue Feb 21, 2021
This roll includes:
- fix for Windows start
- crashpad disabling
- refreshed Firefox Beta @ Feb 19, 2021

Fixes #4660, fixes #4780
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants