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

[Bug]: Local storage items set via browser.newContext() missing for an iframe in Chromium #32230

Open
nbaldzhiev opened this issue Aug 20, 2024 · 3 comments
Assignees
Labels

Comments

@nbaldzhiev
Copy link

nbaldzhiev commented Aug 20, 2024

Version

1.45.3, but it is present in ANY version >1.37.1

Steps to reproduce

  1. clone https://github.com/nbaldzhiev/playwright-chromium-iframe-storage-state-bug;
  2. install the project (npm install and npx playwright install);
  3. debug test in tests/foo.spec.ts with a breakpoint at await page.pause();
  4. open the browser's devtools and navigate to the Local Storage section;
  5. select origin https://clausa.app.carto.com.

Expected behavior

The local storage item set during browser.newContext() call, for an external origin which is embedded into an iframe, is present in Chromium.

Example in Firefox
Screenshot 2024-08-20 at 15 11 28

Actual behavior

The local storage item set during browser.newContext() call, for an external origin which is embedded into an iframe, is missing in Chromium.

Screenshot 2024-08-20 at 15 36 28

As a result, we have failing tests because the user ends up being not automatically logged in to the application loaded by the iframe since the access token is missing from the local storage (which is how we perform the authentication, i.e. we set specific items in the local storage, via browser.newContext(), and the FE identifies us).

If in that repo you roll back to 1.37.1 and run again, it works as expected - the local storage item is present in Chromium.

Additional context

It would be great if this can be prioritised, because it is currently BLOCKING us from updating our Playwright version and we are stuck at 1.37.1, which is 1 year old now.

The test application is basically just a iframe tag with a src pointing to a URL with another origin.

Environment

It happens in any environment (also tested in linux github actions runners), but here's my laptop's:

  System:
    OS: macOS 13.4.1
    CPU: (8) arm64 Apple M1
    Memory: 137.39 MB / 16.00 GB
  Binaries:
    Node: 20.14.0 - ~/.nvm/versions/node/v20.14.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v20.14.0/bin/yarn
    npm: 10.7.0 - ~/.nvm/versions/node/v20.14.0/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: 1.45.3 => 1.45.3 
@Skn0tt
Copy link
Member

Skn0tt commented Aug 22, 2024

In your example, it looks like the iframe is on carto.com while the main frame is on web.app. iframes can only access parent localstorage if they're on the same domain. You'll need to either bring them onto the same domain, or use something like the Storage Access API to share the localStorage.
To double-check that this is what's happening, try this outside of Playwright in a normal browser. Does it work there?

@nbaldzhiev
Copy link
Author

nbaldzhiev commented Aug 22, 2024

But this is working on 1.37.1 where we currently are stuck at because we can't update due to this issue here. Therefore, our setup is just fine since it is currently working fine.
Also, as I've mentioned, it works in Firefox, only not in Chromium (with versions >1.37.1).

And about "trying outside of Playwright", I think the issue comes from the fact that local storage items set through browser.newContext() get ignored, because you can see that there are other local storage items there, but not the one set via browser.newContext(). So, in that sense, I am not sure how much sense it makes to try this "outside Playwright"

@Skn0tt
Copy link
Member

Skn0tt commented Aug 22, 2024

Apologies, I hadn't looked at the repro close enough. I can reproduce and we'll look at fixing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants