It appears that one of the scripts loaded by the Tilt Forums site is preventing the site from loading on Firefox 76. The site does load when I block scripts using NoScript, but all of the pretty formatting is gone when I do that.
The same problem seems to happen on Edge (both legacy and the new Chromium based one).
It’s working fine on the latest Pale Moon, FWIW.
I’ve done some more testing, and it’s actually something a bit more sinister. It turns out that Firefox and Edge are adding “www.” to the beginning of the url behind-the-scenes, and it appears that www.tiltforums.com doesn’t work while just tiltforums.com appears to work.
edit: I am an avid user of the CTRL+Enter shortcut to complete URLs, and that seems to cause the problem. This is made more annoying with the latest browsers hiding the “www”.
Having a similar problem on Chrome.
ok looks like mine hung on www. but it turns out I’m always on here at just tiltforums.com not www.
I think pale moon only adds the www if there’s no response without.
Heh. I’ve noticed this under Chrome and Firefox on Linux, Windows, and Android. All this time I’ve been having to get into this site via a “backdoor” link (searching Google for “site:tiltforums.com”).
With and without www both point to the same digital ocean ip. Should be a minimal config thing to get the www to forward properly.
/also a free letsencrypt.org cert would make modern browsers happier
I’m guessing then that the www domain is another DNS A record instead of a CNAME.
www, modern browsers will refuse to execute it.
Odds are that
http://www.tiltforums.com just needs to be added to the site config in this manner: https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243#heading--extend-default-csp
It looks like Discourse rolled out CSP fairly recently, so maybe the site was just upgraded?
I haven’t been able to get it to work on mobile for a few weeks. Figured I needed to clear caches or something but didn’t want to go down that route. The googling trick solved it - genius!
Hey! Sorry I had read this and it fell off my radar. I have enabled www. in the CSP policy as described above, and it appears to be working. However login cookies are not crossing the domains, so you can login on one and then not be logged in on the other. Long term I think redirecting all traffic to one or the other is the solution, and I’ll look into that when I get a moment.