Thanks @Don, 100% repro for me as well. Testing using BrowserStack this looks like a regression after Safari 17, I get no repro on Ventura (Safari 16.5), but can repro on Sonoma (Safari 17.3). I have reported the above steps and findings upstream to Webkit, this should help them track this down.
7 Likes
Yay, reproducible steps! 
Can also easily reproduce it in our forum (3.2.4). The key seems to be the navigation back step, as that triggers the bug, regardless of initial or intermediate page (I tried topic, category, FAQ, badges, etc).
While Webkit looks into this (I imagine it will take a while for a fix to reach a production release), would it make sense to try to pin down the particular change in Discourse from which it started to surface the bug in Safari and, if simple&feasible, potentially have a local workaround? In our case, it only started showing up after we recently updated from 3.1.5 to the latest stable. A big window, but maybe iterating through the betas first and go from there?
2 Likes
PS: Just to add that, now that I can reproduce it, I tried to temporarily disable the PWA on our main website and it didn’t seem to make any difference for this. So… not multi-PWA related.
So I’ve just try it on Chrome too and I noticed a really odd thing. If I understand it correctly it should only happens on Safari? I thought it but maybe I am wrong. Because I can repro it in Chrome browser too on iPad. So it seems the issue is with the OS? Is this also reproducible with MacOS under Chrome? 
Or it’s only affects iOS and iPadOS on Chrome too because of the webkit issue?
My understanding is that Apple doesn’t allow third-party browsers on iOS/iPadOS, so Chrome/Firefox/etc are just a specialised GUI, all using Webkit to render pages behind the scenes.
As the issue is on Webkit, any browser running on iOS/iPadOS is affected.
6 Likes
Yes that’s it 
Although this is changing Using alternative browser engines in the European Union - Support - Apple Developer
3 Likes
Thanks for prodding us on this @mentalstring, after bisecting, I think there is a very likely culprit in: DEV: Change default of `cross_origin_opener_policy_header` (#24940) · discourse/discourse@38abc0d · GitHub
From a test in one of our instances, running SiteSetting.cross_origin_opener_policy_header = 'unsafe-none' on the Rails console or adding this to your ENV:
DISCOURSE_CROSS_ORIGIN_OPENER_POLICY="unsafe-none"
fixes the issue. That site setting is a security hardening measure, we’re evaluating the pros/cons of updating core as well, but if you (and others following this issue) could try this out on your end, that would be great, it would give us more confidence that this is indeed the underlying change in Discourse.
3 Likes
A-ah, there it is then!
I can confirm that setting COOP to 'unsafe-none' has effectively stopped the bug from showing on our 3.2.4 instance. Toggling back to same-origin-allow-popups immediately brings it back.
It’s good to have some kind of temporary workaround. Meanwhile, I imagine this is likely useful info to report to the Webkit team since it points to something specific that triggers it.
PS: Thank you for looking into this and sorry about the prodding – I’m just fumbling around trying to help our community. 
2 Likes
Just to prevent others from missing it too, this bit should be:
DISCOURSE_CROSS_ORIGIN_OPENER_POLICY_HEADER: unsafe-none
1 Like
A followup here folks: a WebKit developer merged a fix for this issue a few weeks ago. I tried to test it using the nightly WebKit builds, unfortunately, I can still reproduce the problem. However, I may be doing something wrong. Will wait for the next Safari Technology Preview release (it should be soon) to test again, hopefully it is indeed fixed. (WebKit bug report is here.)
2 Likes