This is only a recent development
That's irrelevant. It's here now.
(half the reason Chrome caught developer's eyes so early on was its amazing out-of-this-world JavaScript performance)
If you ask me, Chrome's javascript interpreter, or at least it's implementation of certain behaviours, is broken.
Let's say I want to pop off an analytics pixel at unload time. We need a little delay to ensure the image request gets sent, so we shove in this little gem:
var s = e = new Date();
while (e.getTime() - s.getTime() < 500)
{
e = new Date();
}
There! Works in every browser! Except Chrome- "Error: Too much time spent in unload handler"
OK, no problem. We'll just change it to this.
var s = e = new Date();
while (e.getTime() - s.getTime() < 1)
{
e = new Date();
}
whew, glad that's out of th "Error: Too much time spent in unload handler."
So... one millisecond is too long? Is that what the error means? Why is chrome the only one that has this limitation? Guess though! Turns out that this error is a lie- it had nothing to do with the amount of time spent in the handler. It should really read, "Chrome detected you're trying to delay unload to ensure a pixel request goes through. Even though the only way to accomplish this is by delaying unload, we're going to be total dicks about it and pre-empt your attempt".
I mean, I can understand preventing too long of a delay, but basically providing a handler and refusing to do anything useful in it? What is that supposed to do?
You might think "well it's for security rite" Which I might agree with. The purpose if this code, by the way, is to try to keep track of what link was clicked to leave a page. I ended up working around it by creating my own Mini URL shortener service and having those links in the DB, so the page that redirects to it can record the link hit. Then I removed it because it was a pain in the *censored*, so now my DB has empty fields where the counts should be. One might argue that "anything that tracks the user is inherently bad even if the purpose is to increase site usability"... Of course that sort of falls apart, since you can get the proper behaviour by just using this:
var s = e = new Date();
for( var i = 0; e.getTime() - s.getTime() < 500; i++)
{
e = new Date();
}
So, why doesn't the original code work? It's some weird bit of hueristic done by chrome to prevent... well, I'm not sure. It's quite targeted. you can use a while() loop, it doesn't trigger the error. Nor does calling getTime() on it's own. But if you call getTime in the condition or body of a while loop, poof- "too much time spent in unload handler".
it's really quite targeted. A while() loop alone doesn't trigger the behavior, nor does calling getTime() alone. But if you call getTime() in the condition or body of a while() loop, bam. I don't remember reading about this error being thrown in those specific conditions in the ECMA specification. The best I can tell is it was designed to prevent infinite loops in the BeforeUnload handler. I can totally understand preventing infinite loops in BeforeUnload handlers, because- duh. Thing is if the above behaviour is designed to do that, they missed a bunch of other ways to lock up their own browser:
var img = document.createElement('IMG');
img.src = 'http://url_i_want_to_load.png';
img.loaded = false;
img.onload = new Function('e', 'this.loaded = true');
while( !img.loaded )
{
CodeToTrickChromeIntoThinkingThisCodeDoesSomethingUseful();
}
In that segment (mostly psuedocode) the while condition is never going to occur, because the image's onload handler cannot be trigger while in the middle of another handler. So, one might expect the browser to do toe usual "chug along for 30 or so seconds, complain about "this page stopped responding" and prompt to close it,right?
Nope. the tab's process pegs the CPU at 100% (or rather high, regardless) until the user forces the tab closed. It's an interesting day at the office when you accidentally learn how to write malicious javascript. Too bad it only works (or worked, they may have fixed this since I discovered it) in Chrome. Also too bad we have to write workaround code- only for chrome, mind you- to "fix" their special "prevent infinite loops" behaviour nonsense which doesn't even work.
Anyway- so when I first discovered this- as noted, the problem only cropped up in Chrome. IE? worked fine. IE6? Worked fine. Firefox? worked fine. Opera? don't know. didn't try it. etc. Only Chrome was a problem.
And people give IE a bad rap for making people write workaround code...
One of the major problems is that how browser makers and the W3C hold their hands up to their ears and yell "NAH NAH NAH NAH!!!" whenever the need for web analytics comes up. There really should be support for something this simple in the spec. Analytics aren't inherently evil, and if it's in the spec, one can control exactly what kind of information is kept track of, and what can be done (like not showing alerts and so forth). It's not like a server side page can't already track all sorts of stuff like refering URLs and IP addresses and whatnot. Seeing how people are leaving the page is hardly a bad thing.
Than again, all the browsers have their issues. I rather like
this bug from 2001..
I'm not sure what about scripts between the CSS...
I have to echo your confusion...
