Bug 196318 – REGRESSION: [ITP 2.1] Storage access not granted to the original page after user interacts with the Google Sign-In popup

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKit Misc.

[Satoshi Ohno]

We recently noticed an issue starting from STP 77 (and STP 78) where storage access isn't granted even when the popup is not auto-dismissed.

More specifically: document.hasStorageAccess() still returns false after the popup is closed with a user interaction.

This seems to be in conflict with the "Removed Compatibility Fix for Popups" section in the ITP 2.1 blog post (https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/), where the access would be granted if the popup is not auto-dismissed. Therefore I think this is a bug.

Here are the reproduce steps.

1. Make sure that the 3rd party domain is considered prevalent, in this case, google.com.
2. Open a website implementing Google Sign In. For example, let’s use soundcloud.com.
3. Click on the signin button up top. This would load the iframe under the accounts.google.com domain.
4. Open the console and change the scope to sslFrame_google (iframe). Run document.hasStorageAccess(). As expected this would resolve to false.
5. Click on “Continue with Google”. A popup under accounts.google.com will be opened. Interact with the popup by clicking on a signed in Google account or signing in a new one. The popup will then close.
6. On the opening browser, the page will not sign in the user and will appear as if nothing happened.
7. If you run document.hasStorageAccess() again under the sslFrame_google (iframe) scope, the promise would still resolve to false.

Please let me know if we could help to reproduce this issue!

[Radar WebKit Bug Importer]

<rdar://problem/49357992>

[John Wilander]

Thanks for reporting. We've heard a couple of other reports too so this definitely seems to be a bug.

[Brent Fulgham]

*** This bug has been marked as a duplicate of bug 196407 ***