This took me a while to figure out, but I've isolated the issue. With the default ABE ruleset, when the ABE rules check is run on a non-local site, and that site references a local resource, it will do a blocking DNS query, locking up the browser! The trace is through localDestination where it does a blocking DNS query.
[ABE] http://external site/dns_test.htm Checked in 0
[ABE] Waiting for DNS query on hqnveipbwb20
[ABE] DNS query on hqnveipbwb20 done, 2252ms
[ABE] Local destination DNS check failed for http://hqnveipbwb20/public/style_images/ipb-30-nvgreen/rte_icons/rte_arrow.png from http://external site/dns_test.htm: 2152398878
Does the destination domain actually resolve? The log suggests it might not.
However, ABE's DNS requests are ALWAYS non-blocking (at least in Firefox 3.0 and above where explicit event loop spinning is available):
First, ABE checks whether the DNS info exists in its cache and if it doesn't suspends the channel (actually it's a bit more complicated than that, but the effect is the same) and starts DNS resolution with a callback to the repeat the checks when the DNS records are finally in the cache. This is absolutely non-blocking: all the other networking and the UI event loop are unaffected.
However if the DNS records are still missing after resolution (i.e. asynchronous resolution failed with NS_ERROR_UNKNOWN_HOST (2152398878), the DNS request might be repeated by local checks (like in your case, when it seems to fail again). This DNS request is ASYNCHRONOUS too, even though in this late (and edge) case ABE needs to know the answer in the same code unit (it can't use a callback to the checks), and therefore waits on the UI thread for an interenal callback BUT in the meanwhile spins the event loop: therefore, albeit this is a semi-syncrhonous scenario, neither the UI nor the networking should get locked.
The URL doesn't/isn't supposed to resolve. You're saying though that it should still be responsive during the event spin? In particular with this test case, the ABE rule is being called from a CSS restyle, where the texture has been cleared, so the window is entirely black and unresponsive.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
In FF4 with direct2d the entire window, not just the content window is blacked out and unresponsive, navigation included.
In FF3.6 it doesn't black out, but the entire window is unresponsive, including navigation.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
