Safari not showing "Post" text entry box on MacRumors Forum

[Makosuke]

I've now twice had a really weird issue with my Safari install at work and these forums: I can't post because the text entry box (both on the "new post" page and in reply to an existing thread) just isn't there:

Just a blank white area when it's supposed to look like this:

I tried many combinations of cleaning caches and data, and so far as I can tell the only way to restore normal functionality is:
1. Close all open MR windows.
2. Delete all website data.
3. Use the Develop menu to delete all caches.
4. Quit Safari and re-open it.

After (and only after) doing all of that did I get a usable Forum. Even then, it was still kinda messed up: I was logged in, and showed as logged in, unless I tried to view the main "Forum List"; that instead re-directed me to the trending page with a login link at the top instead of showing me logged in. Clicking "log in" told me, accurately, that I was already logged in. I rebooted and that seemed to resolve that issue, although then it took a weirdly long time for the text entry field to appear (maybe a minute; it seemed to be stalled loading some Javascript).

Work computer is running Tahoe 26.3.1 (IT requirements) and home is running the latest of everything (although at the time this happened at home, I was probably on 26.1 or 26.2). The network here is a university and is NOT locked down (no proxies, almost nothing blocked from access), nor is the computing environment, plus it happened at home, so I don't think its related to some kind of content blocking or corporate network filtering.

Has anybody else seen this? I at first thought it was a fluke, but it's happened both at home and at work now, and at work I just had to deal with it the second time.

 

[Nermal]

Has anybody else seen this?

Yes. It happened to me a couple of days ago but simply reloading the page fixed it. I thought it was just a glitch so I didn't investigate further, so it's interesting to see another report of it. I'll raise it with the site admins.

I'm not sure whether I was at home (Safari) or work (Firefox) when it happened.

 

[Makosuke]

Thank you, and it's interesting that reloading fixed it for you, since that most certainly was not sufficient on my system--I of course tried that first, as well as multiple other unsuccessful cache-clearing routines.

I should have noted that Chrome on both of the computers in question was okay at exactly the same time, so at least for me it was browser specific.

An aside, this has caused me to realize something: While my "old web" brain thinks of the reload button as meaning "ask the server for everything again and replace whatever is in the cache", that is no longer the case, and I've seen other situations where a page has some kind of issue with the cached Javascript so parts of it aren't working, and just reloading doesn't help because it's not actually replacing what's in the cache.

 

[arn]

Hmmm. Lemme look into this

 

[arn]

testing...

 

[arn]

ok, I think I fixed this. It was a caching related issue. Let me know if it happens again

 

[Makosuke]

Wow, thanks for digging into that, and quickly!

Hopefully that was indeed it, but I’ll certainly speak up if it happens again.

 

[Makosuke]

Well, it did indeed crop up again.

This time I was a little more careful and ran a timeline using the Develop tools, and came up with a couple of things that may or may not be relevant:

It turns out the post box isn't actually "not there", it's just taking an incredibly long time for something on the backend to either load or process; I hadn't caught that the loading indicator wasn't completing. Just about all content loads within the first 2 seconds or so, but the page then sits doing nothing for 270 seconds, at which point load of 72726X1523008.skimlinks.js (from s.skimresources.com) and gtp.js (from www.googletagmanager.com) complete loading, a flurry of additional rendering and script activity happens, an api call is made to r.skimresources.com, page load completes, and the text entry box appears.

Trying it a few more times, the delay seems to be somewhat irregular (a second try was about 83 seconds, this thread was rapid, and the fourth try was again exactly 270s), but the pattern looked the same.

Whether those load completions are a red herring or not, I'm not sure, but I'm kinda guessing the Google resource just has to do with tracking and it's the skimlinks scripts or behavior that's directly or indirectly causing this.

It's possible this has something to do with our campus network or management system, but we're on a fat pipe with virtually no filtering and a wired gigabit connection to my desk, Chrome on the same computer at the same time doesn't do this, and I've also seen what looks like the same issue at home on a different Mac.