Fx2 post 1.9.5 iframe regression

[al_9x]

1) forbid iframes, set no placeholders for untrusted
2) goto http://www.betanews.com/ which contains an ad iframe near the top
3) you will see Fx2 briefly load the "offline mode" error page in the iframe, which is then replaced by placeholder
4) this "offline mode" flashing wasn't there in 1.9.5
5) now mark the iframe domain as untrusted and reload
6) now since there is no placeholder, the "offline mode" error page will stay in the iframe.

[therube]

You may have found Tom's issue, 1.9.6.2 and .6.5 causing "Offline" error message.

5) now mark the iframe domain as untrusted and reload

I'm too slow to figure that one out, but I get the idea.

Now, if I get it figured, I'll post a screenshot.
(You know what they say about a picture... In Tom's thread, I was expecting to see a status bar notification or the like of "Offline" rather then the dialog message as I now see flashing by.)

And it will even throw a ClickJack warning.

Let's see if this is good for a "picture".

Copy & paste into the URL bar:

Code: Select all

about:neterror?e=netOffline&u=http%3A//adserver.adtechus.com%23/adiframe/3.0/5159/429982/0/225/ADTECH%3Btarget%3D_blank%3Bkey%3Dkey1+key2+key3+key4%3Bgrp%3D1867207762&c=UTF-8&d=Firefox%20is%20currently%20in%20offline%20mode%20and%20can%27t%20browse%20the%20Web.

And it may also be related to the issue seen by, Empty network error pages. (Maybe I'm pushing it with that one?)

Picture (like its not obvious ):

[Tom T.]

1) forbid iframes, set no placeholders for untrusted
2) goto http://www.betanews.com/ which contains an ad iframe near the top
3) you will see Fx2 briefly load the "offline mode" error page in the iframe, which is then replaced by placeholder
4) this "offline mode" flashing wasn't there in 1.9.5
5) now mark the iframe domain as untrusted and reload
6) now since there is no placeholder, the "offline mode" error page will stay in the iframe.

Yes, the error is identical, but the cure doesn't work for me.

What I do realize is that Yahoo uses banner ads. Nearly all of Yahoo's advertisers are already in my Untrusted list. This is proven by the fact that the NS logo is solid blue at Yahoo. Yet I get the error message, and I get it at http://www.betanews.com even after marking adtechus.com (the domain of the banner iframe placeholder) as Untrusted. I'm going to add this to my thread, and test it at some other sites that use banner ads. I don't visit very many of those, other than Yahoo.

[al_9x]

Yes, the error is identical, but the cure doesn't work for me.

I think you misunderstood, there is no cure.

[Tom T.]

Yes, the error is identical, but the cure doesn't work for me.

I think you misunderstood, there is no cure.

Yes, I misunderstood #6,

6) now since there is no placeholder, the "offline mode" error page will stay in the iframe.

to mean that the error page would stay in the *blocked* iframe, and since the iframe was blocked, you wouldn't see the error message. Sorry.

It does sound like our issues are related. Hopefully, the additional info from this thread and from mine, which therube linked, will help Giorgio to diagnose it.

...And it will even throw a ClickJack warning....

I don't get that in my set of symptoms.

BTW, not that it matters, I get the much simpler error messages, not the kind shown in your screenshot. If you toggle
browser.xul.error_pages.enabled to False, you'll see what I mean. Just smaller and cleaner, not of any significance.

[Giorgio Maone]

Some weirdness was kind of expected because I noticed a change in how latest Gecko 1.8.x series builds handle request lifecycle and had to add an "Only from cache" restriction to the requests to be blocked in order to block them reliably.
I'm investigating how to mitigate the side effects.

[al_9x]

Some weirdness was kind of expected because I noticed a change in how latest Gecko 1.8.x series builds handle request lifecycle and had to add an "Only from cache" restriction to the requests to be blocked in order to block them reliably.
I'm investigating how to mitigate the side effects.

Just want to make sure I understood, you adjusted NS to the latest 1.8 gecko used by Seamonkey, presumably, which broke Fx2.0.0.20 which uses an older 1.8 gecko? Is that right?

[therube]

Gecko 1.8.1 is the same for both SeaMonkey 1.1.17 & FF 2.0.0.20.

If a change was made it was made for Gecko 1.8.x & not SeaMonkey specifically.

Actually, there could be differences between the two.
FF is at 1.8.1.20, & SeaMonkey is at 1.8.1.22.

SeaMonkey 1.1.17 will continue to have security fixes (though no real development) for a while yet.
It looks like FF 2 will have no further changes whatsoever.

[al_9x]

Gecko 1.8.1 is the same for both SeaMonkey 1.1.17 & FF 2.0.0.20.

Compare our browser agent strings. 1.8.1.20 vs 1.8.1.22

[therube]

(yes, I was just editing to reflect that)

Oh, & I have observed the issue in both SeaMonkey 1.1.17 & FF 2.0.0.20.

[Giorgio Maone]

Just want to make sure I understood, you adjusted NS to the latest 1.8 gecko used by Seamonkey, presumably, which broke Fx2.0.0.20 which uses an older 1.8 gecko? Is that right?

Yes, it's correct. The adjustment was made for Gecko 1.8.1.x, and therefore affects both Fx 2.0.x and SM 1.1.x. I didn't bother to fine-tune for build id, also because I can't tell for sure when exactly the old blocking method ceased to be 100% reliable in Gecko 1.8.1. All I know for sure is that it happened after 3.0.0 became official.

[al_9x]

Just want to make sure I understood, you adjusted NS to the latest 1.8 gecko used by Seamonkey, presumably, which broke Fx2.0.0.20 which uses an older 1.8 gecko? Is that right?

Yes, it's correct. The adjustment was made for Gecko 1.8.1.x, and therefore affects both Fx 2.0.x and SM 1.1.x.

I am still confused, I thought you made the adjustment for the sake of latest SM which uses gecko 1.8.1.22, and Fx2.0.0.20 didn't need it.

But evidently that's not correct? So Fx2.0.0.20 needed this change that introduced these bugs, meaning that NS 1.9.5 with Fx2 has a problem and is not blocking something? Can you expand, what is the issue?

[Giorgio Maone]

So Fx2.0.0.20 needed this change that introduced these bugs, meaning that NS 1.9.5 with Fx2 has a problem and is not blocking something? Can you expand, what is the issue?

The situation is a bit complex.
Every supported version of Gecko (i.e. >= 1.8.1) blocks stuff fine from a strict active content blocking point of view: requests to be blocked are guaranteed to die before the data is processed by the content viewer (either the browser document viewer or a plugin), and that's all (i.e. in some circumstances, e.g. when we need to perform content sniffing, hitting the network is OK - the active content won't run anyway because we download and process the headers only, not the request body).

Then enters ABE.
ABE's blocking is very tricky in regard of timing: it must happen after DNS resolution (because we check stuff like internet->local requests and now we check also subnetworks), but it must happen before the request is sent, which is a much stricter requirement.
There's nothing built-in in the browser supporting this kind of timing, therefore ABE uses lots of neat tricks to accomplish this task.

Now, Gecko 1.9 and above supports aborting a request during the nsHttpChannel::asyncOpen() call, either in a http-on-modify-headers observer or in a web progress listener (NoScript is both), and guarantees a request aborted at that time won't hit the network. This is good for ABE, even though not perfect because at the time asyncOpen() is called DNS records are not necessarily cached. However ABE does some very acrobatic magic to cope with this situation, and it incredibly works.
Unluckily, while testing ABE on Seamonkey 1.1.17 I suddenly realized that the no network assumption for requests aborted in nsHttpChannel:asyncOpen() on Gecko 1.9 is not valid for older Gecko versions. The reason is this difference.

So, to recap, a blocking method used in a very few cases (when content sniffing is needed) in NoScript "classic", is good enough for NoScript classic's requirements (it hits the network but doesn't download more than the HTTP headers and anyway prevents content processing), but can't suffice for ABE's requirements on Gecko 1.8.1.
Therefore I decided to "harden" late aborting as much as possible on Gecko 1.8.1 so that ABE can be supported (even if with performance penalties unrelated with this issue) and NoScript's "classic" behavior is more efficient (less networking) and predictable.

But believe me, I'd prefer to drop Gecko 1.8.1 entirely, and I will almost surely do it as soon as Seamonkey 1.x dies.

[Giorgio Maone]

Can you check latest development build 1.9.6.96?

[therube]

No longer seeing the issue.

(PS: Just pointing to that one Bug reply of yours doesn't do things justice. You really have to read from the top .)