InformAction Forums

Posted: **Tue Feb 15, 2011 7:31 am**

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.

The log file

Code: Select all

[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

The test case is

Code: Select all

<html>
<head>
<style>
.c1
{
	background-image: url(http://hqnveipbwb20/public/style_images/ipb-30-nvgreen/rte_icons/rte_arrow.png);
}
</style>
</head>
<body>
<a onmouseover="javascript:document.getElementById('request').style.display='block'">hover over me</a>
<br />
<div id="request" class="c1" style="display: none">a block</div>
</body>
</html>

Posted: **Tue Feb 15, 2011 11:04 am**

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.

Posted: **Tue Feb 15, 2011 12:11 pm**

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.

Posted: **Tue Feb 15, 2011 12:33 pm**

AzuiSleet wrote:he window is entirely black and unresponsive.

The content window, or the whole browser?
In other words, do you retain the ability of navigating away from that page, for instance?

Posted: **Tue Feb 15, 2011 12:36 pm**

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.

Posted: **Tue Feb 15, 2011 3:38 pm**

That's weird. I'll investigate, thanks.

InformAction Forums

ABE DNS requests to LOCAL are blocking

ABE DNS requests to LOCAL are blocking

Re: ABE DNS requests to LOCAL are blocking

Re: ABE DNS requests to LOCAL are blocking

Re: ABE DNS requests to LOCAL are blocking

Re: ABE DNS requests to LOCAL are blocking

Re: ABE DNS requests to LOCAL are blocking