What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 129 Stack Exchange communities.

Some buttons ("vote" and "accept" buttons) disappeared with Google Chrome 11. What is the reason?

share|improve this question

migrated from stackoverflow.com Apr 29 '11 at 14:38

This question came from our site for professional and enthusiast programmers.

    
This question appears to be off-topic because it is obsolete. –  Rosinante Jul 13 '13 at 16:54
    
@Rosinante Since when were old questions suddenly off-topic O_o –  ɥʇǝS Jul 13 '13 at 17:31
    
Since they deleted 'too localized'. –  Rosinante Jul 13 '13 at 17:44

8 Answers 8

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.)

share|improve this answer
1  
That worked for me too -- thanks so much! –  Ernest Friedman-Hill Apr 29 '11 at 14:45
    
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! –  Cawas Apr 29 '11 at 16:51
    
By the way, would you know why that happened, Arjan? –  Cawas Apr 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. –  Arjan Apr 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. –  Cawas Apr 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. –  Cawas May 6 '11 at 22:58
    
I believe I was the author of that earlier question. Restarting the browser helped for me. –  Ikke May 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:

    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 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.)

share|improve this answer
    
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
    
+1 for the diagnostics ... impressive post –  waffles May 28 '11 at 12:00
    
@Jeff, if you're still investigating then see the last bullet I added. –  Arjan Jul 22 '11 at 7:19

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

share|improve this answer
2  
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.

  • 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
share|improve this answer
    
Is this on SO only? And do you get any Javascript errors? –  balpha May 6 '11 at 19:37
    
@balpha How embarrassing. Updated with JS error. :) –  Isaac Truett May 6 '11 at 19:46
    
Can you check in the Network tab of the Dev tools if the request for wmd.js gets made an returns successfully? –  balpha May 6 '11 at 19:48
    
Added contents of Headers tab for wmd.js. –  Isaac Truett May 6 '11 at 19:54
    
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 Truett May 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... –  Arjan May 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...) –  Arjan May 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. ;-) –  Arjan May 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. –  Arjan Jul 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!) –  Arjan Nov 19 '11 at 11:42

It's working fine for me on a Linux installation (Natty Narwhal Ubuntu).

share|improve this answer

I'm on Chrome 11 with both Mac Snow Leopard & Windows 7, I've never had any problems. Are you up to date?

share|improve this answer

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

share|improve this answer
    
See the updated code.google.com/p/chromium/issues/detail?id=62712 -- no solution, but maybe you can do some testing too. –  Arjan Jul 20 '11 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. –  Arjan Jul 24 '11 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.

share|improve this answer

You must log in to answer this question.