You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
const{chromium}=require('playwright');(async()=>{constuserDataDir='/Users/donaldbough/Library/Application Support/Google/Chrome/Profile 3';constbrowserContext=awaitchromium.launchPersistentContext(userDataDir,options);//Do stuff that requires my user to be logged in})();
Describe the bug
For context, I'm trying to re-use a Firebase Auth session across my tests. Firebase saves their sessions in IndexedDB, so naturally, I tried persistent authentication. I was using the data directory for a separate Google Chrome profile to not interfere with my main profile. After going to chrome://version I found the profile path was /Users/donaldbough/Library/Application Support/Google/Chrome/Profile 3'.
After manually logging in on that Google Chrome profile, I observed the auth session was saved and then tried to launch with persistent context from Playwright. I noticed the auth session wasn't being loaded as expected. So when looking at chrome://version on the Chromium window launched by Playwright, I noticed it had changed the profile path from .../Profile 3 to .../Profile 3/Default. When looking at the difference between those two directories, I saw they both had their own IndexedDB folder. So after copying the IndexedDB folder from .../Profile 3 to .../Profile 3/Default, the auth session was persisted as expected.
My Request
The ideal solution would be for chromium.launchPersistentContext to not modify the user data directory parameter and use it as is. I understand that this is probably being done by Chromium at some point when it's trying to load the user's data directory. If this bug is something that is in Chromium and not Playwright, a note in the documentation mentioning this behavior would be extremely helpful to others as well. I'd be willing to submit a PR for documentation changes if that turns out to be the best solution.
This took a while to figure out, so a code or documentation update would be great to save others from experiencing the same headache.
Thanks!
The text was updated successfully, but these errors were encountered:
This is just chrome://version showing the profile path with the /Default at the end. Chromium has a notion of "user data directory", and it can store multiple "profiles" inside. The default one is stored under .../Default. Let me see what we can do with documentation.
Context:
Describe the bug
For context, I'm trying to re-use a Firebase Auth session across my tests. Firebase saves their sessions in IndexedDB, so naturally, I tried persistent authentication. I was using the data directory for a separate Google Chrome profile to not interfere with my main profile. After going to
chrome://version
I found the profile path was/Users/donaldbough/Library/Application Support/Google/Chrome/Profile 3'
.After manually logging in on that Google Chrome profile, I observed the auth session was saved and then tried to launch with persistent context from Playwright. I noticed the auth session wasn't being loaded as expected. So when looking at
chrome://version
on the Chromium window launched by Playwright, I noticed it had changed the profile path from.../Profile 3
to.../Profile 3/Default
. When looking at the difference between those two directories, I saw they both had their own IndexedDB folder. So after copying the IndexedDB folder from.../Profile 3
to.../Profile 3/Default
, the auth session was persisted as expected.My Request
The ideal solution would be for
chromium.launchPersistentContext
to not modify the user data directory parameter and use it as is. I understand that this is probably being done by Chromium at some point when it's trying to load the user's data directory. If this bug is something that is in Chromium and not Playwright, a note in the documentation mentioning this behavior would be extremely helpful to others as well. I'd be willing to submit a PR for documentation changes if that turns out to be the best solution.This took a while to figure out, so a code or documentation update would be great to save others from experiencing the same headache.
Thanks!
The text was updated successfully, but these errors were encountered: