I noticed from my web server logs that MSIE browsers (versions 6
through 8) were yielding tons of 404 errors by requesting a "null"
file in whatever directory the current request was being served out
of. E.g. a homepage request would be followed by "/null", and a blog
request with "/blog/null".
I was able to narrow this down to the BlockUI plugin, and more
specifically, the GrowlUI function within it. These growl alerts show
up on every page load, so it was explained why I saw so many 404's in
the logs. Debugging the script to find the source of the "null"
requests was a lot harder, but I finally traced it down to the default
CSS used for the Growl overlays rendered by BlockUI.
Most BlockUI overlays assign:
...via CSS, but the Growl overlay's default CSS replaces "wait" with
sets up the overlays, this default CSS is merged with the optional
plugin argument and assigned in its object form with jQuery.css().
For some reason, all recent versions of MSIE seem to interpret the
null value of the "cursor" key as a string and end up hitting the
server's local directory for a file by that name.
I have no idea if URL's are actually permitted for the CSS cursor
property, but I'm familiar with the usual options of "wait", "help",
"move", etc. In any event, I'd have expected any URL reference for a
CSS property to be wrapped in "url()", but I'll chalk this up as an
MSIE quirk (or undocumented feature).
I was able to fix this by swapping out literal null for "default",
which maintains the intended functionality of having a standard
I'd hesitate to call this an important "bug", although it was for us
(these 404's were actually causing redirect loops in our webserver).
Moreover, this is probably something that would never come up in unit
tests, since I doubt MSIE's cursor file request happens completely
silently. I do think it worthy of being patched in BlockUI, and
perhaps this could yield an upstream ticket for jQuery if the cursor
property requires special interpretation within the css() function.