Reproducible with Firefox 34 Beta 10 - BuildID: 20141117202603 Environment: Mac OS X 10.9.5 Steps to reproduce: 1. Start Firefox with a clean profile. 2. Go to about:config and set layout.css.filters.enabled=true, then quit and restart Firefox. 3. Open a new tab and navigate to http://codepen.io/samthejarvis/pen/rpIKz. 4. In the CSS panel look for instances of "-webkit-filter" and change them to "filter" (there should be 3 of them)... each time wait for the change to be applied and content to reload. 5. Choose to close the tab by clicking on "x". 6. In the confirmation dialog that appears click either Stay or Leave. Expected results: Tab closes without issues. Actual results: Firefox hangs and doesn't respond to any interaction. User needs to force quit it. Same thing happens if instead of closing the tab you click the Back button or try to navigate to a new page. This is came up while testing the implementation of CSS filters in bug 948265, and seems to be related to the filters (though I cannot say for certain). This reproduced only on Mac (consistently), and only with this page... no such issues came up while testing on Windows 7 x64 or Ubuntu 14.04 x64.

Thank you for this testcase!! What seems to happen is that long-running refresh driver ticks swamp the event loop in such a way that no native events get processed. This is a problem with our Mac event loop setup. I've noticed the problem multiple times before couldn't find a reliable way to reproduce it. But your STR reproduce the problem with 100% reliability for me.

It'll be a while before I can get to this. In the meantime, Markus, could you get some stack traces that illustrate the problem?

Here's a stack. So we have: -[NSApplication run] -> -[GeckoNSApplication sendEvent:] -> native mouse up event processing -> JS event handler that spins nested event loop for modal dialog -> nsThread::ProcessNextEvent -> only Gecko events processed here So basically, nested event loops under native events cause no more processing of native events if Gecko events keep coming in.

I think I see this same problem during startup session restoration, and sometimes during normal browsing if Firefox Sync starts syncing (which it does with nested event loops) and an expensive animation is running: The browser keeps animating, but it doesn't respond to any input events.

The proximate cause is probably that either nsAppShell::ProcessNextNativeEvent(bool aMayWait) isn't being called at all (during these hangs), or that it's always called with aMayWait set incorrectly.

I just saw this with an ad that was hogging the event loop and opening the "Clear Recent History..." dialog