User Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 Steps to reproduce: We, the FoxyProxy team, offer an API for webdevs to change the proxy settings of a FoxyProxy user after she confirmed that. In order to do so a notification box is shown which asks her if she wants to allow that. If not, she might click on the notification box' close button (the "x") and the notification box vanishes leaving her settings untouched. I attached a minimal example xpi containing the code of this feature. In order to reproduce the freezing install the xpi in a new profile and load the second test case on http://ford.getfoxyproxy.org/developers/api-test.html ("Set to Disabled Mode with Callback") clicking on the Go-button. Then click on the close button of the notification box. Actual results: Firefox beta (i.e.) 13, aurora and nightly are freezing (nothing is clickable in the content window) at least on Linux and Windows 7 until one e.g. clicks on an item of the menu bar or the Firefox button (on Windows). This does not happen using Firefox up to and including 12 or Seamonkey (even the nightlies are working). Expected results: The alert triggered by the callback should have shown up immediately.

So, I've bisected that and the culprit is: http://hg.mozilla.org/mozilla-central/rev/d7dcde1032ed

The chrome document's nsRefreshDriver::Notify calls nsTransitionManager::WillRefresh (in the Flush_Style observers), which synchronously fires a transitionend event, which eventually (via the test XPI) enters an alert(). During the alert(), if something happens that needs a repaint, we have to reenter nsRefreshDriver::Notify() but that's difficult to do for the chrome document; nsRefreshDriver::EnsureTimerStarted finds that mTimer is non-null and bails out. A non-root-document nsRefreshDriver firing an alert() isn't nearly so bad since at least the root-document nsRefreshDriver can still be entered to paint the window. That's why an alert() in a transitionend in Web content normally doesn't cause any problems. The problem here is that alert() is being called from the chrome document's nsRefreshDriver, which we wouldn't normally allow to happen. So I think that making the chrome document's nsRefreshDriver handle nested event loops spun in Notify() would not be worthwhile. FoxyProxy is doing this: if (callbackObj.rejected) callbackObj.rejected(); It could work around this problem by wrapping the call to rejected() in a setTimeout(0).