Indistinguishable from Jesse

If you use Google Cache when a server isn't responding, and the page uses an external style sheet, you won't be able to see the cached page. The reason is that most browsers block page display while waiting for the style sheet to load, and Google doesn't cache CSS or images. This limits the usefulness of Google's cache, especially now that CSS is popular.

Google could cache CSS along with HTML. To avoid spidering and storing every page's CSS, Google could proxy CSS loads for Google Cache users, and have the proxy time out after 5 seconds. But both of these solutions might use a lot of bandwidth.

Google could add code to cache pages to make CSS load later or in a non-blocking fashion. This has the disadvantage that when the server is responding, the page will be presented unstyled for a split-second. Since some Google users use the cache even when the site isn't down, this would be bad.

I hoped there would be a way for Google to add code to cache pages to stop blocking loads that are taking too long. JavaScript can detect a slow load: call setTimeout above the LINK element, and call clearTimeout in another SCRIPT element below the LINK. But the function setTimeout activates can't cancel the load by disabling the style sheet, changing the LINK's href, or removing the LINK element from the document. Browser makers didn't anticipate JS trying to cancel a blocking load. (Removing the LINK element from the document even crashes IE.)

Another solution is for browsers to make CSS loads block less:

• 84582#c11 - CSS loads should stop blocking layout if they take more than a few seconds
• 220142 - Pressing Stop while waiting for CSS should finish displaying what has been loaded before stopping.
• 224029 - JS can't cancel blocking load of a style sheet

A spammer posted the following comment on my old blog post Chrome URLs in Mozilla and Mozilla Firebird yesterday:

I've been a long time user of both IE and Netscape. Now I'm using Mozilla and Firebird. Although I'm a fan of Mozilla and Firebird and have recommended it to friends.

The poster's URL had a spammy-looking domain name ("success-biz-replica"), but the site itself didn't look too spammy and the comment seemed fairly on-topic, so I didn't delete the comment. But today I stumbled on a very similar comment here and realized the comments were spam. The spammer probably decided to spam blogs mentioning Mozilla because those blogs are likely to have high Google PageRank.

I went into my web server logs to see what search phrase she used. I figured it would be something like mozilla "post a comment" "remember personal info" but I wanted to see the exact search phrase. I searched for the poster's IP address and found this:

193.230.197.6 - - [26/Oct/2003:11:07:05 -0800] "GET /archives/000007.html HTTP/1.0" 200 12252 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Alexa Toolbar)"

There was no referer, which probably just means she hid the referer intentionally. But I noticed something else: she used Internet Explorer to post the comment.

I deleted the comment.

I attached simple patches to 3 Firebird bugs:

213377 [5] - Cannot stop animation with stop button or escape key 216722 [3] - Inital focus in Help|About Mozilla Firebird should be "OK" 218146 [0] - mousedown on tab and drag out still switches to tab (fix: switch onmousedown instead of onclick)

I hope my patches fare better than the ones mentioned in this forum thread.

Webmasterworld's "hitchhiker" and I found a security hole in Google today. He searched for something like "this can't be true" and his browser reported a JavaScript syntax error. I pointed out that with a carefully constructed query string, you can get Google to spit out something syntactically valid that does whatever you want. For example:

http://www.google.com/search?q='+alert(document.cookie)+'
causes Google to generate the following onClick attribute: onClick="c('http://images.google.com/images?q='+alert(document.cookie)+'
&hl=en&lr=&ie=UTF-8&c2coff=1&safe=off','wi',event);"

If you follow the link and click a tab (web, images, groups, directory, news), you'll see your Google cookie in a dialog.

Hitchhiker responded:

I just can't believe G made that kinda mistake.

ESCAPE ESCAPE!

Escaping is not always the best solution. When I found a similar hole in some JavaScript code in Mozilla, ducarroz's solution was to use an alternative window.setTimeout syntax. The normal version of setTimeout takes a string to be parsed and executed; the alternative version takes a function and parameters. Instead of escaping the untrusted input, we avoided parsing a string containing the untrusted input.

• Mozilla: 59.6% (76.6% Firebird)
• MSIE: 27.5%
• Opera: 2.3%
• KHTML: 1.2%
• Other: 9.4% (includes robots)

If all goes well, Mozilla Firebird will be released early next week. Here's a list of changes since 0.6 that I consider important.

I will turn 21 on October 13, 2003.

On an unrelated note, here's the list of Mozilla bugs I reported that are still open and the list of bugs I'm voting for.

Twice this week I have witnessed Mudd students recommending Mozilla Firebird to other Mudd students. Both students mentioned pop-up blocking and tabbed browsing. One also mentioned themes, Flash Click to View and other extensions, and the customizable search bar (he uses IMDb and dictionary.com in addition to Google).