googleapi.com, Firefox 3, <script … /> and security

Public service message: firefox 3 does not play well with self closed script tags.

I discovered this when I was repointing my jQuery libraries toward the googleapis hosted versions, to take advantage of their speed. I tested the switch in Opera, where it looked fine. Later, doing some debugging with firebug, I noticed those pages were no longer executing any javascript. Chrome had no problem loading them, and initially I thought the jQuery lib was the issue, but curling a new copy proved it was identical to my locally hosted version. Finally I noticed the difference in how I had self closed the script tags, which is perfectly legal… firefox 3 just doesn’t like it.

So I like the ajax.googleapi.com hosted libraries, although I don’t buy that using the google.load() method is better than pointing to the hosted library directly. Profiling the difference between two pages that do nothing more than load jquery shows that using google.load() adds about 0.2 seconds to the load time. Try it yourself:
Pointing directly vs Using google.load(). Which only makes sense, since loading the google api takes time… so where is the extra “power” they boast you receive by using this method? The only potential advantage I see is the ability to load the library conditionally, avoiding the load unless you need the library. I say potentially because I’ve yet to make use of that kind of just-in-time loading. If you have, or I’ve overlooked some strength to this method, I’d love to hear it.

One last googleapi related note: using a script tage to call your library, you can use https to load the file. The google.load() method appears to load files using http, which is quicker but poses a security risk by injecting insecure code into a supposedly secure environment. This is the same reason secure method pages should use the secure-only flag on cookies: you are only secure as your weakest link.

Leave a Comment

Name (required)

Mail (will not be published) (required)

Website

Comment