[Feature] Option to disable ITP / cross-site tracking prevention?

[alexduhanov]

Hey all,

I recently updated my project to Playwright 1.25.2 and ran into a situation where some of my tests, which rely on ITP being disabled for Safari, are now failing.

Interestingly, these tests only fail when I run playwright locally on macOS Monterey -- when I run the same tests inside of a linux Docker container using the same verson of Playwright 1.25.2, the tests pass. Perhaps this is due to a difference in the way Playwright's webkit binary is compiled for linux vs macOS?

In any case, I was wondering if there is a way to recreate disabling this Safari option when running tests against webkit:

Thank you!

[mxschmitt]

This is related to #17285, #16937 and #17047.

So it was working at a previous WebKit version?

[alexduhanov]

@mxschmitt

Comparing to the other github issues you linked: in my case, the workflow/test is not dealing with iframes--only CORS calls. Additionally, webkit doesn't prompt any pop-ups.

To reiterate: I do expect the workflow/test to fail with modern versions of Safari, unless the "prevent cross-site tracking" option (as in the screenshot) is not selected; this is the observed behavior when the workflow is executed in actual Safari 16.0 on my machine. As such, I was simply hoping to replicate disabling this option within playwright/webkit.

But yes, this was working in older versions of Playwright. I just went back through every minor version and found that the test last passed in Playwright 1.17.2 / webkit v1578. As of Playwright 1.18.1 / webkit v1596, the test begins to fail.

As I mentioned, I observed that these tests do in fact pass in Playwright 1.25.2 / webkit v1699 within Docker (using mcr.microsoft.com/playwright:v1.25.0-focal as the base for my compose file), which seems a little odd to me; they only fail when I execute playwright directly on macOS.

Please let me know if I can provide any additional information.

[mxschmitt]

Yeah the networking stack on macOS is different to linux/windows thats why its not occuring there.

Our WebKit is afaik not considering the Safari settings, that's why it has no effect.

We have not decided yet if we want to disable ITP by default, we do it in Firefox, since it was there a regression between 1.24 and 1.25.

[mxschmitt]

Some debugging notes for the future:

• v1588 was the last good version
• it's based on where the binary gets compiled. webkit-mac-10.15.zip is good, while webkit-mac-12.zip is bad.
• after 1.17 we dropped 10.15 support, that's why we run into it then.

[RobinClowers]

I'm also running into this issue, there is no pop up, the cookies just aren't sent unless 3rd party tracking is turned off. This is only the case on localhost, on a real domain they are sent correctly. I'm not sure that's because of the domain, or because it's not https, but either way, it makes testing on Webkit much more difficult.

[kkortes]

Any updates on this? Did you successfully get into a position where you can run webkit tests @alexduhanov ? We're facing the same issue.

I've been looking for a way to tell playwright how to launch webkit safari and mabye provide a launch option to disable this but no luck :(

[alexduhanov]

@kkortes It's been a while but IIRC I ended up disabling those failing tests for webkit and just let them run through Chromium - I don't believe I was able to find a solution at the time. Was hoping to hear an update from the Playwright devs at some point, as they haven't yet closed this issue.

[oprypkhantc]

In our case, we're running the tests on a app.something.loc domain, while the API sits on api.something.loc. Safari considers requests from app to api as cross-site, hence does not send the cookies due to cross-site tracking protection.

This is ONLY happening with non-registerable domains, e.g. private tlds like .loc. If you try the same exact thing with a registerable tld, like .com, it all works as expected with ITP on.

There really needs to be an option to disable ITP, as it does not work for development/testing environments the same way it does for everything else :(

[oprypkhantc]

@mxschmitt Would you accept a PR with a patch to WebKit that changes the way it treats .loc, .local, .localhost TLDs to be the same as regular ones? E.g. to make WebKit treat app.something.loc/api.something.loc domain pair the same way it treats app.something.com/api.something.com?

[mxschmitt]

@oprypkhantc this sounds more like an upstream WebKit bug: https://bugs.webkit.org/ - does it also affect normal Safari?

Maybe using an official domain and rewriting its host entry would be a workaround?

[oprypkhantc]

@mxschmitt It is, and it does affect Safari as well, but there's been no movement in related bug reports:
https://bugs.webkit.org/show_bug.cgi?id=218980
https://bugs.webkit.org/show_bug.cgi?id=254991

Which is why I'm hoping we can at least fix this for Playwright :)

Rewriting with hosts file is not an option for us, unfortunately. We maintain a multi-tenancy app that also uses dynamic subdomains. So basically tests run against hundreds of domains generated dynamically. As /etc/hosts does not support wildcards (at least on macOS), we're using dnsmasq to forward all .loc TLD queries back to 127.0.0.1. Since it's a private TLD, it doesn't conflict with any of the public sites.

So using an "official" public TLD would also require forwarding all of the queries to 127.0.0.1, which would in turn break all access to websites using it. A while ago we used to use .dev TLD and it was a pain :)

Then there are issues with self-signed certificates and possibly other issues as well, so we'd rather not use any public TLD.