Michael Teper

The customer in this case is me. You can catch all the gory technical details in my previous post.

The gist of the issue is that the popup blocker that is part of the Google Toolbar has a nasty way of silently defeating certain Internet Explorer functionality that may have absolutely nothing to do with popping up an annoying ad. The worst part about it is that Google Toolbar is otherwise a fine piece of software that does give you both visual and sound cues when it catches and stops popups.

This started two days ago when I discovered that part of functionality of our application ceased to work under Internet Explorer 6 and was data was being lost. I could easily reproduce the problem on a few machines in the office (all with IE6 and up to date on latest patches) but the problem did not appear on a virgin install of Windows 2000 with an older version if IE. After a day of getting nowhere in my testing and trying various changes to code, I contacted Microsoft Support and initiated a $245 support incident. Another day went by during which I exchanged a number of emails with the Microsoft tech until he suggested I check what Browser Helper Objects I had installed on my machine. It turned out I only had two: Acrobat Reader and Google Toolbar. A quick Google search (ironic, no?) revealed that in its early days Google's popup blocker was doing nothing more that disabling exactly the functionality I was now missing. Bingo!

To sum up, Google Toolbar disables the browser “onunload” event whenever the browser window is being closed. It does so indiscriminately of whether there is any code there that tries to launch a popup. Moreover, it does so without any indication to the user that it had altered the intended site experience. It cost me two days and $245 to track this down. Now, I have to figure out how to get around it. So far, Google Toolbar support has not responded to my email.

Just think the kind of furor would ensue if Microsoft were to do something like that? Guess what though, the MSN Toolbar's popup blocker manages to do its thing without such nasty side-effects. As does the Yahoo Toolbar.

For the record, as of this writing the Google Toolbar is at version 2.0.110-big/en (GGLD).

Raymond Chen gives an interesting insight into the elections to the board of directors of Allstate.

In other words: These thirteen people will be elected to directorships regardless of what you do.

Read the full post here.

[Update: This blog post sets up the problem, though it appears I was pointing the finger the wrong way. It turns out the problem was caused by Google Toolbar. See my followup post for more details.]

The JavaScript / JScript onunload event is notoriously unreliable from browser to browser. Reading though various USENET posts leads me to believe that the behaviour is slightly different between Mozilla derivatives, Opera, and IE. That sucks but is nothing new. What is, however, annoying is that behaviour differs on the same browser.

A few months ago I coded up some functionality that persisted state back to the server when the user left the page. I used the onunload event and the HTTPPost function. I tested it on XP and IE6 (my primary dev environment) and all was well. Recently, I started noticing that I don't get all state info I should be getting. I dug a little deeper and found that the onunload event is no longer firing when the browser window is closed by the user. It still fires if the page is refreshed or if the user navigates to another page. This is still on the same development machine with no other code changes involved. What gives? Well, the only thing I can think of is that in my diligence to apply every security patch Microsoft puts out, I've applied something that broke the onunload event. That is to say, Microsoft broke IE behaviour with respect to the onunload event. I say “broke” because their documentation states that to invoke the event, the user has to “Close the current browser window.” (this is the first item in a long list of actions that should trigger the event).

[rant]
This is the kind of breaking change that should be avoided, or at least damn well documented. If there is really a compelling reason to drop functionality (for security reasons or whathaveyou), please, PLEASE, tell us about it!!!

Today, because this is causing loss of data, I have to drop everything and try to figure out if there is a way to hack onunload behavior back in. My biggest fear is that I may have to completely rearchitecture the way this part of the application works. What's worse, is that even if Microsoft fixes this in the next WindowsUpdate patch, there will now be a (potentially large) pool of users for whom the current implementation will not work, making the onunload event forever useless to me.

Grrr!!!!
[/rant]

To test this functionality, copy and paste this code into a new file:

</body>
</html>

Open the file in IE. Hit F5, see the message. Navigate to another page, see the message. Close the browser window. If you see the message, please let me know what version of IE you are using...

update 1: I found this Scandinavian post on what seems like the same subject. If someone out there could translate the gist of it into English for me, I would really appreciate it!

update 2: I am working with Microsoft Support to investigate / resolve this issue.

update 3: It turns out the problem was caused by Google Toolbar (at version 2.0.110-big/en (GGLD) as of this writing). You can see my follow-up post for more details.