[Feature] Support "context.setStorageState()"

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]

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

[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)