I trust you mean [Empty the Cache](chrome://settings/clearBrowserData) - crap, the linking didn't work! Anyway, I did it just the Cache and just for the past week, and it's all good now! Thanks!
–
CawasApr 29 '11 at 16:51

By the way, would you know why that happened, Arjan?
–
CawasApr 29 '11 at 16:56

1

No, @Cawas. It's a bit odd, as Stack Exchange tends to append some dummy ?v=... to the URLs, to ensure browsers know they should get a new version of the script even if previously they were told they could cache it. But so far I've only seen Chrome users complain, so I guess it's a Chrome fault. @YOU suggested it might have something to do with the new inline Markdown help, but then all browsers should have had this problem.
–
ArjanApr 29 '11 at 17:04

I like the new inline markdown help on comments, but my issue wasn't even the same as the one reported here. So yeah, it's probably Chrome's fault as you say, but I'm not so sure it's related to an old script version - after all in my case everything worked in incognito and I had no issues before even with the Markdown already implemented.
–
CawasApr 29 '11 at 17:11

@Cawas: These problems started appearing when Chrome updated to version 11. My guess is that versions 10 and 11 handle cached files slightly different and that this difference can be causing problems. The closest I could find (I'm not sure it's related, but it might be) is code.google.com/p/chromium/issues/detail?id=77841
–
balpha♦May 4 '11 at 7:17

@balpha I've already had to clear my cache about 10 times, because now random sites on SEN keep breaking, even the same ones do it again. Your link is too much for me right now, but I hope this info is somewhat valuable. I always clear only the cache and only for past day or past week, and it always solve for the site I'm on. But sometimes I'm with many SEN sites loaded in different tabs and I usually have to go and clear the cache again for each one.
–
CawasMay 6 '11 at 22:58

I believe I was the author of that earlier question. Restarting the browser helped for me.
–
IkkeMay 27 '11 at 22:34

Some more debugging info. Sorry for the huge post; hopefully it's just temporary :-) I still feel that Chrome is messing up, but maybe it helps investigating...

It seems that, when I get the issue, clearing the cache and not using a forced reload when things are fine, keeps me out of trouble. (If things are fine, then Command-R seems okay, but Command-Shift-R might break the cache, requiring one to clear it again.)

It seems incognito mode gets me the issue a bit more often, but I also get the same in normal mode. However, I've not been able to get the same issue here on Meta. Note that Meta gets its JavaScript from /content/js, not from the cookie-less sstatic.net domain. However, that also applies to, for example, full-anon.js which shows no issues.

When things are fine, in incognito mode a Command-Shift-R refresh often does not refresh wmd.js (maybe just some optimization, but most others do get a full reload with 200 OK).

After clearing the cache, one needs to restart Chrome to ensure the cache is cleared for incognito mode too. (Maybe a new incognito session suffices.)

If all is fine, I get Content-Length: 17095 and Content-Type: application/x-javascript:

For a normal Command-R refresh (here in incognito mode), when getting 304 Not Modified for wmd.js, all is fine too:

But when things go bad, then for a normal Command-R refresh (here in incognito mode), when getting 304 Not Modified for wmd.js the Content-Type is shown as "pending". The request seems to be the same as for another SE JavaScript resource. The 304 responses for full-anon.js and wmd.js both do not specify the content type, which seems fine to me:

When things have gone bad, for a forced Command-Shift-R refresh all resources are requested unconditionally, except for wmd.js. While for all other resources Pragma: no-cache is requested, the request for wmd.js shows the odd Range: bytes=17095-17095, and If-None-Match: ..., the latter indicating a conditional refresh. Wireshark does not reveal an earlier request asking for (or getting) bytes 0-17093 or something like that. Note that the offsets for Range should be zero based, like Range: 0-17903 and Range: 17904-17904 for a length of 17905; Range: 17905-17905 is simply invalid here.

Just before things go bad, chrome://view-http-cache/http://sstatic.net/js/wmd.js?v=c6b732291db9 shows an odd RESPONSE_INFO_TRUNCATED, while at the same time it then displays the page just fine, but only once. The Chromium source code claims: This bit is set if the request was cancelled before completion. That does not match what I am seeing in Wireshark, but I might be wrong. After that, as long as things are bad, the same result shows for the cached content:

Changing the dummy query string works fine then. It gets me the same Etag, but I doubt that would confuse Chrome. (If, for different SE sites, different dummy values for ?v= yield the same Etag, then that should really be fine. Also, I've cleared my caches and tested using just a single site, assuming the Most Visited overview in a new Chrome tab does not actually make any requests, like Safari's Top Sites does... In fact: chrome://view-http-cache/ only shows the ones I expected.)

Both full-anon.js and wmd.js are loaded by stub.js, whereas stub.js and jquery.min.js are loaded directly using things like <script type="text/javascript" src="...">.

In July 2011, someone at xing.com reported a troublesome JS file that always shows this issue in the current Chrome 12 when loaded from their servers using HTTPS, but not when loaded from another server or when using HTTP. Changing the JS file to be a bit longer fixed the problem for them. See Chromium's issue 62712 for details.

(Of course, I am normally not using incognito mode. I've no extensions installed in Chrome.)

oddly enough I can repro this on chat (a core chat js file) with exactly these symptoms. Very random, of course, never personally seen this problem before today but does smell like a Chrome bug to me.
–
Jeff Atwood♦May 27 '11 at 10:14

The pointer to jquery.min.js:16 isn't really helpful; unfortunately since jQuery 1.5, there's a try/catch block that just reraises the exception, so any exception that happens during a $() call will be raised at the same point in the code (that said, it's pretty clear where the exception actually happened)
–
balpha♦Apr 29 '11 at 14:58

I started experiencing JavaScript problems with Stack Overflow and Chrome a few days ago also. At first, clearing the cache and refreshing the page worked. Now, I can't get the toolbar and post preview to show up at all.

Hmm. I really don't understand the purpose of the Range header here. It doesn't make any sense to me to send that. -- Anyway: You said "No recent extension installations to blame"; I take that to mean that you do have in fact extensions installed. Does the same thing happen when you deactivate them all? And/or using incognito mode?
–
balpha♦May 6 '11 at 20:27

I can reproduce the same behavior incognito. The problem may be more intermittent than I originally thought: I sat here hitting ctrl+shift+r on the /questions/ask page and watching the results. Every now and then the missing controls would appear and stay for a few refreshes, but then disappear again. I tried various combinations of refreshes, closing the tab and opening a new one, navigating to another page, and any other voodoo rituals I could think of. Nothing 100% reproducible yet. Any chance this could be a stale file somewhere served up due to load balancing or solar flare variations?
–
Isaac TruettMay 6 '11 at 20:51

@balpha, and that figure "17095" even is one too large for a zero-based offset with a length of 17095...
–
ArjanMay 7 '11 at 13:21

@balpha, as wmd.js is loaded through JavaScript: would you happen to know if somehow aborting the script from which the download originated would also abort fetching wmd.js? (Even then, I am not sure if it's relevant. But at least: the only difference I see between wmd.js, stub.js and /jquery.min.js, is that only the first is loaded through JavaScript? And the RESPONSE_INFO_TRUNCATED I get apparently means This bit is set if the request was cancelled before completion...)
–
ArjanMay 7 '11 at 16:01

@Arjan full.js is also loaded delayed, and that includes commenting functionality -- which seems to work. My suspicion (and I have to rely on guessing because I have not been able to repro) is a concurrency bug in Chrome. I've checked in a fix to hopefully work around that (I don't know if it's deployed yet, I'm not near a computer right now).
–
balpha♦May 7 '11 at 17:54

@balpha, I get the same issue, still with the same value for v in wmd.js?v=c6b732291db9 on Super User with revision 2011.5.8.1. I even forgot to use incognito mode (it seemed the issue occurs more often in incognito mode). I was not logged in. Like earlier, I am getting full-anon.js just fine, and getting "pending" for the content type for wmd.js. (Note that full-anon.js also showed pending for a short while, but then for all columns, not just the content type.) I still cannot get the same issue to show on Meta (which uses /content/js.) I like the name of setCacheBreakers. ;-)
–
ArjanMay 8 '11 at 9:15

@balpha, if you think folks are still running into this issue: someone has linked to an example of a troublesome JS file that ALWAYS shows this issue when loaded from their server, but not when loaded from mine; see the updated Chromium issue 62712.
–
ArjanJul 20 '11 at 20:43

(And only now I see that "cache breakers" is not about fixing this specific Chrome issue, but about appending things like ?v=123!)
–
ArjanNov 19 '11 at 11:42

If you're NOT using HTTPS, can you tell us where to find the troublesome JS files? I wonder if hosting the very same files from another server will still show the same issue. Of course, securing the files somewhere on your own server and adding a link to the Chromium bug 62712 would be great too.
–
ArjanJul 24 '11 at 13:48