facebook like iframe loaded by object tag not abe blocked

[al_9x]

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

Code: Select all

Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny INC

[Giorgio Maone]

Investigating, thanks.

[Giorgio Maone]

Should be fixed in latest development build

[al_9x]

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)?

[Giorgio Maone]

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.

[al_9x]

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?

[Giorgio Maone]

// 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.

[dhouwn]

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?

[Giorgio Maone]

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).

[dhouwn]

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

[Giorgio Maone]

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

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