[Feature] Support "context.setStorageState()"

[kettanaito]

trafficstars

Proposed functionality

A new setStorageState() API on the context object that applies any given storage state to the current page.

context.setStorageState({ path: '/storage.json' })
context.setStorageState({
  cookies: [...],
  origins: [...]
})

This API is opposite in its functionality to the existing context.storageState() that flushes the storage state to the disk.

Use case

The Authentication docs showcase a great example of creating a browser context, performing sign-in, and storing that session in a JSON file. However, to use that session file you need to create a new browsing context. This is not suitable when using @playwright/test and wanting to control auth state per test.

The recommended example shows that we can create separate contexts with a different session, and that works great, but you lose the ability to use the already existing context that gets created by the Playwright test runner. You also lose any custom fixtures as they are attached to that default context.

In general, I see no reason not to have the "read" functionality for the session state.

Implementation

You're already using this logic in Playwright, it's just internal:

https://github.com/microsoft/playwright/blob/1303e3e355fcdfd4e7f66650dbd9fca6645db5e3/packages/playwright-core/src/server/browserContext.ts#L512-L537

I propose to abstract it into a general function, dropping internals like this. _settingStorageState, and reuse it in the new page.setStorageState() API.

[kettanaito]

I'm open to implementing this if you find the suggestion applicable. I could use some guidance on where to declare the setStorageState public API though. I wasn't able to find a suitable place for it after browsing the source code for a while.

[mxschmitt]

Storage state includes cookies and local storage, both of them are NOT isolated on page level, they are rather isolated on the browser context level, since the browser context is the in-memory browser profile in this case.

I think this makes the whole feature request invalid, wdyt?

(context.setStorageState on the other hand would be a valid feature request)

[kettanaito]

@mxschmitt, I believe so. I don't have a strong opinion on what's the best surface to apply this. Since it's the context that holds cookies/storage, I see a context.setStorageState() as a great API to have in addition to storageState() (which, I believe, is also exposed on page.context() and never on the page directly).

That doesn't make the feature request invalid. Perhaps I need to rephrase it. We need an API to apply a given state JSON to any existing context. This doesn't seem invalid in any way, both because it's conceptually a valid use case and because it's a matter of applying cookies and local storage items to a context, which is completely possible with the existing API (apart from the local storage, which requires to resort to page.evaluate()).

Edit: I've updated the feature proposal to reflect on the context change.

[mariaceo]

This would be helpful for us too. We use API requests in our tests to create the setup faster. And API authentication requires a code that can only be generated if we login in a browser, which we cannot do if we reuse authentication.

[viraxslot]

My use case:

1. I have many roles and credentials to test
2. I want to save storageState-s on-the-fly for many users and reuse them in the following tests
3. Credentials with the same meaning are different on 2 testing environments (so I linked them to the custom projectName test option)
4. I use custom fixtures with PageObject pattern

What I can't do right now

1. I can't call test.use({ storageState: 'something' }) on describe level because outside the test projectName doesn't exist. And I don't want to duplicate my test cases.
2. I can't create a new context inside the test with storageState because it's not obvious how to replace the page in PageObject (and debug mode gets nuts honestly).

So setStorageState() could really help. Currently, I decided to set cookies manually, much easier.

[pavelfeldman]

Why was this issue closed?

Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.

If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.