Bug 274310 – Using Cross-Origin-Opener-Policy HTTP header disables the back/forward cache

• Component: New Bugs
• Status: RESOLVED FIXED

[Penar Musaraj]

This is hard to describe, I'll do my best, but happy to clarify further if there are questions. 

I have Webkit (Safari on macOS) as my daily driver, and in my usage, I am often on two websites that are built using the same underlying web stack. The app is Discourse, so in my day-to-day I'm often switching between alpha.discourse.org and beta.discourse.org. Since 2-3 months ago, I have noticed an issue when clicking links or navigating using back/forward actions between the two sites: the content of the page gets mixed between the two properties. Some assets like avatars, site logo will be loaded from the alpha site, but other elements will be loaded from the beta site. The address bar URL also gets corrupted, it doesn't go to the right location. 

This has been reproduced by multiple colleagues on: 

- Safari desktop macOS (latest version of Safari and the OS as of writing)
- mobile Safari on iOS
- Safari in a webview in iOS
- no repro on non-Webkit browsers

If it's related, there is also an issue navigation to other properties. This is intermittent, but sometimes a link to a Github repository will get stuck in a loading state indefinitely. The browser will start loading the page, but it won't complete it. (I have been mentally forcing myself to open all github links in new tabs to avoid this, but sometimes I forget...)

[Radar WebKit Bug Importer]

<rdar://problem/128678196>

[Ahmad Saleem]

@Penar - can we get test credentials and access to both sites to enable us to reproduce this bug?

[Penar Musaraj]

Thanks so much for responding @Ahmad. I can't provide credentials to the exact two sites (one of the two is a private, internal site), but I can give you a path to repro using public sites. 

Site 1: meta.discourse.org, you're free to open an account there (including via "Sign in with Apple", probably quickest for you). 
Site 2: review.discourse.org, you can sign up/in via Github

Once you have an account on both, I can send you a PM with links between the sites so we can attempt a repro (my username on both sites is pmusaraj). This issue is very inconsistent, though, it seems very hard to repro on demand. In our internal usage, we usually repro when user has tabs open on the two sites for many hours a day and/or they have Safari open for multiple days. 

Note also that we have a few other users reproducing this outside our organization, for example, this report: https://meta.discourse.org/t/ios-doesnt-load-css-sometimes/298740/14

[Penar Musaraj]

Another follow-up here. Recently I was able to reproduce the issue between two public Discourse instances. 

Head over to: https://forums.swift.org/t/enable-syntax-highlighting-for-arm-and-x86-assembly/70622 and click on the link in the past post (that goes to Racket Discourse). The page would get stuck loading after clicking that link. 

I can't reproduce this at will, so it may be very hard for someone else to reproduce right away. (After I refresh the tab for example, I can no longer repro.) But worth keeping this link handy in case we can figure out a path to a consistent repro next.

[Penar Musaraj]

We have some more clear and 100% consistent repro steps. 

- Open meta.discourse.org in Safari

- Click on “Guides”
- Go back (using button, gesture, keyboard shortcut, whatever)
- Click on “Our Hosting”, which is a link to discourse.org/pricing
- Observe broken page. `window.location` is still meta.discourse.org, but the HTML is from discourse.org/pricing

Can repro on Safari TP Release 198 (Safari 18.0, WebKit 19619.1.20.7) as well as Safari Version 17.5 (19618.2.12.11.6).

[Penar Musaraj]

Testing using BrowserStack as well, and: 

- no repro on Ventura (Safari 16.5)
- repro on Sonoma (Safari 17.3)

[Penar Musaraj]

I have some additional information. It looks like the issue is related to the Cross Origin Opener Policy header. 

We can repro the issue 100% of the time when COOP is set to "same-origin-allow-popups". No repro when it is set to "unsafe-none" (the default). 

I'm happy to set up two test pages on subdomains with the header set to each of these values, if that is helpful.

[Ahmad Saleem]

(In reply to Penar Musaraj from comment #7)
> I have some additional information. It looks like the issue is related to
> the Cross Origin Opener Policy header. 
> 
> We can repro the issue 100% of the time when COOP is set to
> "same-origin-allow-popups". No repro when it is set to "unsafe-none" (the
> default). 
> 
> I'm happy to set up two test pages on subdomains with the header set to each
> of these values, if that is helpful.

Yes - it would be helpful and I will update relevant engineer - once you share the URL (although I think they are already CCed on this bug).

Thanks and looking forward to your help.

[Penar Musaraj]

Thanks so much, Ahmad. Here are the repro examples and steps:

https://d2.musaraj.com
- has Cross-Origin-Opener-Policy: same-origin-allow-popups
- is running an example Ember app, source at https://github.com/ember-learn/super-rentals

https://d3.musaraj.com
- does not have a Cross-Origin-Opener-Policy header at all
- is runnign the same app as d2

Repro steps: 
- click on Grand Old Mansion
- go back in history
- go forward (or click on Grand Old Mansion again)
- click on d1.musaraj.com (just below the About Grand Old Mansion title)

Results: on d2, stuff breaks, the page's history is corrupt and the d1.musaraj.com app doesn't load (if you look at console, its relative assets are being requested from d2.musaraj.com's root instead of d1). On d3, there are no issues with the same steps. The only difference between the two is the header. 

Note also that I tried reproducing this with a barebones HTML page without a JS framework, but couldn't. So the underlying Ember library that is used in building this sample app seems to play a role as well here. 

Thanks again for your attention, appreciated!

[Penar Musaraj]

Created attachment 472063 [details]
screenshot of the issue

[Penar Musaraj]

Got a better repro (thanks to a colleague, David Taylor). 

https://d5.musaraj.com and https://d6.musaraj.com are identical, but d5 has the COOP header, d6 doesn't. The HTML for both is: 

```
<ol>
<li><button onclick="window.history.pushState({}, null, '/foo')">Click me</button></li>
<li>Use browser to go 'back' one step</li>
<li><a href="https://d4.musaraj.com">Then click me</a></li>
</ol>
```

https://d4.musaraj.com has this HTML: 

```
<script>document.write(`window.location is ${window.location}`)</script>
```

Can see that window history gets corrupted with steps followed in d5 but not with d6.

[Chris Dumez]

I'll investigate soon. Thanks for the reproduction case.

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/32001

[EWS]

Committed 282105@main (f2479794724e): <https://commits.webkit.org/282105@main>

Reviewed commits have been landed. Closing PR #32001 and removing active labels.

[Penar Musaraj]

Thanks so much for the fix @Chris Dumez! 

Does today's version of Webkit from https://webkit.org/build-archives/#mac-sonoma-x86_64%20arm64 have the commit of the fix? Because I can still reproduce the issue in the example site provided above with 282508@main from the build archive.

[Penar Musaraj]

Folks, apologies for bumping this again, but the issue remains in Safari Version 18.0.1 (20619.1.26.31.7) on Sequoia 15.0.1.

I have another live test case showing the problem. 

- head over to community.openai.com 
- click on Top, Hot or Categories (or any topic in the main column)
- navigate back to the homepage
- then click on API Reference, which is a link to a page on a shared domain, `https://platform.openai.com/docs/api-reference`
- Boom, page goes blank! 

If I disable the Cross-Origin-Opener-Policy Header feature flag, the issue is no longer there. 

(I also changed the status here to "Reopened", apologies if I am overstepping my role here.)

[Chris Dumez]

(In reply to Penar Musaraj from comment #16)
> Folks, apologies for bumping this again, but the issue remains in Safari
> Version 18.0.1 (20619.1.26.31.7) on Sequoia 15.0.1.
> 
> I have another live test case showing the problem. 
> 
> - head over to community.openai.com 
> - click on Top, Hot or Categories (or any topic in the main column)
> - navigate back to the homepage
> - then click on API Reference, which is a link to a page on a shared domain,
> `https://platform.openai.com/docs/api-reference`
> - Boom, page goes blank! 
> 
> If I disable the Cross-Origin-Opener-Policy Header feature flag, the issue
> is no longer there. 
> 
> (I also changed the status here to "Reopened", apologies if I am
> overstepping my role here.)

I have just filed https://bugs.webkit.org/show_bug.cgi?id=281175 for further investigation. I can still reproduce the issue as well on a build that is supposed to have the fix.