So I have run into cases where breakpoints completely freeze firefox UI and only way to recover is to force quit firefox. To reproduce bug unzip attached file, open index.html and set a breakpoint at base.js:36. Try refreshing firefox.

This are cases where I just give up and open chrome to debug :(

It looks like Firefox becomes very slow when we hit that breakpoint, but doesn't actually hang. I was able to focus on a different line in the debugger editor even though it would often take 10'' or more for the click to register. Anecdotally, it seems to me that debug builds were more responsive then optimized builds. I wonder if there is some weird interaction between MutationObserver, the JIT and Debugger. Also the breakpoint is triggered in a forEach loop which involves self-hosted JS IIANM. Here is a debug session from lldb that shows what is going on a few seconds after the breakpoint was hit in an unoptimized debug build. In this particular case it was in the middle of GC, but other times I ended up in layout code or other places. I don't know what to make of this.

CCing some folks who may be able to dig further.

So the issue is spinning a nested event loop from inside AfterProcessNextEvent(), right? Pretty sure Olli and Steven have been looking into issues like that recently: the Mac event loop gets confused if you do that and event processing stops working right.

> So the issue is spinning a nested event loop from inside AfterProcessNextEvent(), right? One way to test this hypothesis is to see if my "radical simplification" patch for bug 959281 (attachment 8366280 [details] [diff] [review]) clears up the problem.

Yes, that patch makes this bug go away as far as I can tell.

I wonder whether a web page could do this via alert() in a mutation observer...

As far as I know, it can.