I have to admit it’s super hard to reproduce! it’s very inconsistent and we couldn’t find a pattern to it.
2 Likes
@pmusaraj quick Q -
do we think that’s related to discourse as a whole or a specific theme? I couldn’t pin it down to one component yet but thinking whether that may fix it?
I think it’s not a specific theme or component, it likely has to do with Discourse as a whole. I reproduced it earlier this week on a Discourse site that had pretty much no components installed.
3 Likes
Thanks for sharing! Frustrating because the UX is terrible because of it and users have to reload the page or go back. Just trying to be proactive about a workaround
1 Like
This is happening with the new discourse discover sub-domain (safari desktop):
Seems to be random that it happens, not often. Is there anyway to run a diagnosis test when this occurs to uncover problem?
4 Likes
Based on our analysis so far, the discourse sub-domain thinks it’s still the host and then any relative asset/link is broken. Meaning, unless you use an absolute path (say discourse.org/css/main.css instead of /css/main.css) it will work. But it’s a pretty crazy workaround as that would include any icon, image, href, js, css etc.
1 Like
This happens for both Desktop & mobile for Safari only.
- Required page parts (external domain) still appears on Discourse’s log, while they should have being logged on the external domain. Couldn’t debug when it happens
- One workaround (instead of changing all CSS/JS/HREF to absolute path) is to place <base href=“https://mydomain.com/”> in the header of all relevant pages (on external domain)
2 Likes
I have just reported a related issue before being pointed to this, which seems to be related.
We just upgraded to Discourse 3.2 two days ago and since then we are getting reports of a similar issue. Although not CSS related in our case, I think the issue is essentially the same.
After following a link in Discourse to our main website, the browser still thinks it’s on the Forum: the URL in the browser says so (!), and sometimes (some? probably relative) links open in the forum domain instead, with an error saying the forum page doesn’t exist. The reports we have so far are all on iPhone/iPad. I can’t reproduce it at all, but those affected seem to experience it a few times a day. Looking at the Discourse logs, I can confirm that there are several 404 requests to pages that only exist on our main website.
I’m quite baffled at the browser opening one website and showing the URL of another (w/o iframes). Being a Safari bug, I sure hope this is only confined within a top domain, as the security implications otherwise are pretty nasty.
In any case, I think something to keep in mind is that this started happening only after we upgraded to Discourse 3.2, so something changed since 3.1 that is triggering this.
Perhaps a complete shot in the dark, but I wonder if this may be somehow related to PWA apps and how they are handled by Safari? Our main website declares a PWA app – and so does our Discourse forum. Both standalone and with start_url: "/" (ours sets a unique id, but Discourse doesn’t). AFAIK, PWA manifest files don’t specify a particular hostname they operate in, so I assume it sticks to the particular one they are hosted in. In our case, the two PWA’s are in separate subdomains but same domain; in how browsers process that there could have room for messing things up and getting the browser confused. But then again, this is just total guess.
2 Likes
If this is from a common link (in our case it’s a navigation icon at the top), perhaps a target=_blank (or even target=_top?) can serve as a temporary workaround?
As for as I recall we tried that as well as replacing HREF with JS:function which did ‘window.open’ and still same result.
Remember: It is fetching the external page - so DNS to this new domain works fine, however, it doesn’t switch to that domain while executing the script and fetching that page’s relative-path resources. So as I said the internal Safari “base” HREF is not updated/switched by the page fetch - which make it load relative to current “base” domain → 404
Is it possible to load JS or CSS from discourse intentionally?
I’ve tried the target=_blank approach and all reports so far are that the problem is gone. Not prefect, but it’s good to have some temporary workaround until there’s more clarity on this.
FWIW, this doesn’t happen only on user initiated click on a link, but also on a javascript “redirect”.
We use SSO on our forum and set up the logout redirect with the URL of the main website. When a user logs out of the forum and Discourse “redirects” them to our main website, this also triggers the issue in Safari. From a look at the console, this is not an actual 302 redirect, so maybe a window.location.
Thanks for the discussions and debugging here folks.
This workaround is simple enough to try out so I have added it to this site (meta.discourse.org) via a theme component. If it fixes the issue, it would be quite neat because I suspect it can help Webkit devs debug the underlying problem. (And independently, we can also evaluate adding a base tag to Discourse core by default.)
My understanding is that the base tag workaround may help when applied on an external site, as the problem seems to happen after leaving a discourse website.
Is the test being done on meta to handle the specific case of links between two different discourse instances? Or, did I get lost somewhere (quite possible! 
)?
1 Like
Yes, our most common issue has been with links between two discourse instances. I think it’s possible that the base tag workaround could also help if used on the source site (and the destination isn’t a Discourse instance). If the underlying issue is that Safari/Webkit are confusing the base URLs (this is not too far from your PWA speculations above), then adding a different base to either site may help break the wrong assumption that is at the root of the issue? Speculation on my part as well, but worth trying it out.
1 Like
Does this break the DMs button?
It didn’t work for me until I disabled themes using safe mode.
1 Like
Good catch, it does indeed seem to break it. I have disabled the component with the base tag, temporarily.
3 Likes
Hello 
I don’t know I say new or not but tried out now what’s going on on iPad. I noticed it happens every time after page change with browser navigation or slide gesture. Sometimes happens with other cases too. It really easily reproducible on Meta Branded theme home page. With the search bar buttons.
On the video first time go back with browser navigation. Second time go back with slide gesture. Third time go back with click the logo.
7 Likes
Wow yup, those steps reproduce the issue every time for me on desktop Safari. Nice one @Don 
In text form:
-
Open meta.discourse.org in Safari
-
Click “Guides”
-
Go back (using button, gesture, keyboard shortcut, whatever)
-
Click “Our Hosting”, which is a link to
discourse.org/pricing -
Observe broken page.
window.locationis stillmeta.discourse.org, but the HTML is fromdiscourse.org/pricing
8 Likes