Some buttons ("vote" and "accept" buttons) disappeared with Google Chrome 11. What is the reason?
8 Answers
For some reason, you'll have to clear your cache.
(This was asked earlier today, but then deleted by its author. Apparently clearing the cache helped for that user. Also, working in Incognito mode did not have these problems.)
-
1
-
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!– cregoxApr 29, 2011 at 16:51
-
-
1No, @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, 2011 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.– cregoxApr 29, 2011 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 May 4, 2011 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.– cregoxMay 6, 2011 at 22:58
-
I believe I was the author of that earlier question. Restarting the browser helped for me.– IkkeMay 27, 2011 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-lesssstatic.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
andContent-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 forfull-anon.js
andwmd.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 resourcesPragma: no-cache
is requested, the request forwmd.js
shows the oddRange: bytes=17095-17095
, andIf-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 forRange
should be zero based, likeRange: 0-17903
andRange: 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 oddRESPONSE_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:RESPONSE_INFO_TRUNCATED HTTP/1.1 200 OK Content-Type: application/x-javascript Content-Encoding: gzip Content-Length: 17095 Cache-Control: max-age=604800 Accept-Ranges: bytes Date: Sat, 07 May 2011 10:58:01 GMT Last-Modified: Sat, 07 May 2011 00:30:44 GMT Etag: "a7d98604eccc1:0" Vary: Accept-Encoding 00000000: 52 01 00 00 01 98 00 00 5b eb 6d c3 43 01 2e 00 R.......[.m.C... 00000010: bb 07 70 c3 43 01 2e 00 17 01 00 00 48 54 54 50 ..p.C.......HTTP 00000020: 2f 31 2e 31 20 32 30 30 20 4f 4b 00 43 6f 6e 74 /1.1 200 OK.Cont 00000030: 65 6e 74 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 ent-Type: applic 00000040: 61 74 69 6f 6e 2f 78 2d 6a 61 76 61 73 63 72 69 ation/x-javascri 00000050: 70 74 00 43 6f 6e 74 65 6e 74 2d 45 6e 63 6f 64 pt.Content-Encod 00000060: 69 6e 67 3a 20 67 7a 69 70 00 43 6f 6e 74 65 6e ing: gzip.Conten 00000070: 74 2d 4c 65 6e 67 74 68 3a 20 31 37 30 39 35 00 t-Length: 17095. ... 00000150: 31 00 00 00 24 20 1...$ --------------------------------------------------------------------------- 00000000: 1f 8b 08 00 00 00 00 00 04 00 bc bd 0b 5b db b8 .............[.. 00000010: f2 38 fc 55 82 cb 82 8d 1d 07 68 bb e7 6c 82 c3 .8.U......h..l.. ... 000042b0: 07 d4 31 de 3c 83 fe 14 29 25 ec d4 ff 3f 00 0f ..1.<...)%...?.. 000042c0: b8 4a 61 22 c0 00 00 .Ja"...
But, 0x42c0 plus 7 bytes is in fact 17095... Wireshark shows nothing odd about the result. Like I see the expected size in
Content-encoded entity body (gzip): 17095 bytes -> 49186 bytes
.When all is fine, the cache shows exactly the same payload. The first lines, for the headers before the actual payload, vary just a bit. Probably different checksums for the different value for
Date:
:Date: Sat, 07 May 2011 11:51:21 GMT 00000000: 52 01 00 00 01 88 00 00 24 36 35 82 44 01 2e 00 R.......$65.D... 00000010: c1 32 37 82 44 01 2e 00 17 01 00 00 48 54 54 50 .27.D.......HTTP
When things have gone bad, directly requesting http://sstatic.net/js/wmd.js?v=c6b732291db9 in the same incognito session gets me:
This webpage is not found
No webpage was found for the web address: http://sstatic.net/js/wmd.js?v=c6b732291db9
Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found.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 sameEtag
, 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
andwmd.js
are loaded bystub.js
, whereasstub.js
andjquery.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. May 27, 2011 at 10:14
-
-
Yes, all the rich text controls disappeared for me today, and every answer I post I get the captcha. Something is rotten in Chrome land.
This is on the Mac, by the way -- don't know about other platforms yet.
EDIT: There's a Javascript error in the console when I bring up the question page:
Uncaught TypeError: Cannot call method 'initIfShown' of undefined
d.d.extend._Deferred.f.resolveWith
v
d.support.ajax.d.ajaxTransport.send.c
All pointing to jquery.min.js:16
-
2The pointer to
jquery.min.js:16
isn't really helpful; unfortunately since jQuery 1.5, there's atry/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) Apr 29, 2011 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.
- Ubuntu 11.04
- Google Chrome 11.0.696.57
No recent extension installations to blame.
Update: Gosh, the error message would help, wouldn't it?
Contents of the JavaScript console:
pixel.quantserve.com/pixel;r=1341183499;fpan=0;fpa=P0-1145367131-1304363738348;ns=0;url=http%3A%2F%2Fstackoverflow.com%2Fquestions%2Fask;ref=http%3A%2F%2Fstackoverflow.com%2F;ce=1;je=1;sr=1280x1024x24;enc=n;ogl=;dst=1;et=1304710849521;tzo=240;a=p-c1rF4kxgLUzNc:-1Resource interpreted as Image but transferred with MIME type text/plain.
stub.js:1 Uncaught TypeError: Cannot call method 'initIfShown' of undefined
This is only happening on Stack Overflow, as far as I can tell. I'm seeing the toolbar and preview right now on Meta Stack Overflow.
Headers for wmd.js
:
Request URL:http://sstatic.net/js/wmd.js?v=c6b732291db9
Request Method:GET
Status Code:304 Not Modified
Request Headers
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Host:sstatic.net
If-None-Match:"1b9f454caebcc1:0"
Range:bytes=17095-17095
Referer:http://stackoverflow.com/questions/ask
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24
Query String Parameters
v:c6b732291db9
Response Headers
Accept-Ranges:bytes
Cache-Control:max-age=604800
Date:Fri, 06 May 2011 19:51:57 GMT
ETag:"1b9f454caebcc1:0"
Last-Modified:Fri, 06 May 2011 05:27:31 GMT
-
-
-
Can you check in the Network tab of the Dev tools if the request for wmd.js gets made an returns successfully? May 6, 2011 at 19:48
-
-
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? May 6, 2011 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? May 6, 2011 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, 2011 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 fetchingwmd.js
? (Even then, I am not sure if it's relevant. But at least: the only difference I see betweenwmd.js
,stub.js
and/jquery.min.js
, is that only the first is loaded through JavaScript? And theRESPONSE_INFO_TRUNCATED
I get apparently meansThis bit is set if the request was cancelled before completion
...)– ArjanMay 7, 2011 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). May 7, 2011 at 17:54
-
@balpha, I get the same issue, still with the same value for
v
inwmd.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 gettingfull-anon.js
just fine, and getting "pending" for the content type forwmd.js
. (Note thatfull-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 ofsetCacheBreakers
. ;-)– ArjanMay 8, 2011 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, 2011 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, 2011 at 11:42
I'm on Chrome 11 with both Mac Snow Leopard & Windows 7, I've never had any problems. Are you up to date?
I am experiencing the very same issue on another website. I posted a new question on Stack Overflow to discuss it: Corrupt Google Chrome cache
-
See the updated code.google.com/p/chromium/issues/detail?id=62712 -- no solution, but maybe you can do some testing too.– ArjanJul 20, 2011 at 20:40
-
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, 2011 at 13:48
I had the same issue on a later version and with Chrome 11 too. Cleaning cache resolved my problem. Nowadays, I do not have any problem.