InformAction Forums

on first load. Once the facebook dns is cached, a reload is blocked.

fx 3.6.3, NS 1.9.9.81, http://hd.net/insidemma.html

Investigating, thanks.

Should be fixed in latest development build

Fixed. Curious, why is there a placeholder when the facebook frame is loaded by IFRAME (amazon) but not when by OBJECT (abe blocked in both cases)?

al_9x wrote:Fixed. Curious, why is there a placeholder when the facebook frame is loaded by IFRAME (amazon) but not when by OBJECT (abe blocked in both cases)?

Because in order to fix it I had to switch on synchronous DNS requests when and OBJECT is loading a URL whose host is not DNS-cached yet.
Being synchronous, the request and the ABE checks happen before NS blocking.
IFrames and other kinds of requests don't need this, and can rely on asynchronous DNS.

Giorgio Maone wrote:

al_9x wrote:Fixed. Curious, why is there a placeholder when the facebook frame is loaded by IFRAME (amazon) but not when by OBJECT (abe blocked in both cases)?

Because in order to fix it I had to switch on synchronous DNS requests when and OBJECT is loading a URL whose host is not DNS-cached yet.
Being synchronous, the request and the ABE checks happen before NS blocking.
IFrames and other kinds of requests don't need this, and can rely on asynchronous DNS.

// OBJECT elements can't be channel-replaced

Not sure if I understood, does this mean that OBJECT requests can't be cancelled if the async dns resolution is needed? Is that a Fx bug that you had to work around?

al_9x wrote:

// OBJECT elements can't be channel-replaced

Not sure if I understood, does this mean that OBJECT requests can't be cancelled if the async dns resolution is needed? Is that a Fx bug that you had to work around?

Gecko doesn't give you any "official" mean to interact with a request after DNS resolution and before the HTTP payload hits the network (which is exactly the phase where ABE needs to work).
When I implemented ABE, I had to invent something in order not to perform synchronous DNS resolution by myself in an early stage, potentially blocking the UI if the DNS info was not cached, and I came up with this hack: when I've got no DNS cached info, I create a fake internal redirection (even this one required to duplicate lots of networking code, because there's no public API for redirections even) and delay opening the new (redirected) channel with the same URI until asynchronous DNS resolution is completed, thus not blocking the UI and gaining the same perceived performance as the normal Gecko networking. I created an ad hoc class to do this transparently, called "ChannelReplacement", and that's why I wrote "can't be channel-replaced".
Unfortunately OBJECT elements handle requests internally in such a way that internal redirections break. I scanned the Gecko source code to understand why, and if not a bug it seems at least an unexpectedly early release of a certain internal member which should contain the current network channel but contains null instead, but still it's not clear why. So I had to resort to synchronous DNS resolution in this very case.

Giorgio Maone wrote:Gecko doesn't give you any "official" mean to interact with a request after DNS resolution and before the HTTP payload hits the network (which is exactly the phase where ABE needs to work).

Did you ask the Mozilla guys whether they might implement an official interface so you don't need to rely on such hacks in future versions?

dhouwn wrote:

Giorgio Maone wrote:Gecko doesn't give you any "official" mean to interact with a request after DNS resolution and before the HTTP payload hits the network (which is exactly the phase where ABE needs to work).

Did you ask the Mozilla guys whether they might implement an official interface so you don't need to rely on such hacks in future versions?

Yes I did (don't remember the bug # right now, though).

Giorgio Maone wrote:

dhouwn wrote:

Giorgio Maone wrote:Gecko doesn't give you any "official" mean to interact with a request after DNS resolution and before the HTTP payload hits the network (which is exactly the phase where ABE needs to work).

Did you ask the Mozilla guys whether they might implement an official interface so you don't need to rely on such hacks in future versions?

Yes I did (don't remember the bug # right now, though).

One of these?
https://bugzilla.mozilla.org/buglist.cg ... ype1=exact

dhouwn wrote:One of these?
https://bugzilla.mozilla.org/buglist.cg ... ype1=exact

Nope, https://bugzilla.mozilla.org/show_bug.cgi?id=354493#c81