InformAction Forums

I've encountered some firefox 4 misbehavior when using NoScript. Particularly, there appears a double page load under certain conditions.
At least under Windows XP, both with Firefox 4.0b8 and 4.0b9, when loading a text-only page on a whitelisted domain, the page is loaded twice. I discovered this by accident, when saw that the numeric counter, which should increase by 1, increases by 2 on each reload. If I disable NoScript, however, it works as expected (checked repeatedly, enabling and disabling NoScript several times).

Can I see a test case URL?
Does it happen on a clean profile with just NoScript installed?

I'll prepare a test-page for you, since it is currently located on intranet

Not sure of the cause, but I'm not able to reproduce it on a different host. I'll try to do it within a day and report back.
Meanwhile, there is how it looks like in firebug: http://img641.imageshack.us/img641/9338/noscript.png

I doubt it will be of any use, but there is a final description:
As I've already said, there is a text-only page, which I run occasionally. It is located on a host ru.projectname.dev. It, in fact, does not only display a counter, but handles some data, which can be altered on the other page.
The other page is located on http://www.projectname.dev, and is content-rich. Not sure what triggers the behavior, but whenever I refresh this one (it does not address ru.projectname.dev in no way, except maybe cookies for projectname.dev/), the first request on the text-only page is aborted. If I refresh the text-only page several times, it eventually starts loading without aborts, but only until the html page is reloaded again.
As I've already said, projectname.dev is whitelisted in NoScript, and there is no misbehavior if I disable NoScript entirely.

UN wrote:whenever I refresh this one

By which means? F5? reload button? shift+button?

Crtl-R does the job. It is even sufficient to make a single ajax Post request, as I've just discovered.

And you said the counter increments even though the request is aborted?
Does it happen in a clean profile with just NoScript installed?

Giorgio Maone wrote:And you said the counter increments even though the request is aborted?
Does it happen in a clean profile with just NoScript installed?

Yes, there is the same misbehavior with a fresh Firefox profile, with single NoScript for addons.

It appears, that if I disable "Enable ABE" in NoScript options, the bug is gone. Except, I'm completely not sure why a regular page refresh (ctrl-r) triggers the block after some other page made an ajax request.

UN wrote:I'm completely not sure why a regular page refresh (ctrl-r) triggers the block after some other page made an ajax request.

Page refreshes delete the DNS cache.
ABE causes Firefox to put HTTP requests on hold until DNS information is available, otherwise it couldn't block them based on their destination IP (e.g. to enforce anti-DNS Rebinding).
In order to do so, for each request whose host is not found in DNS cache, ABE causes an internal redirection, which aborts the initial request before it hits the network (in Firefox < 4 at least) and replaces with a new one starting as soon as the host gets resolved.
This technique is necessarily hackish because Firefox has no API to block request at a stage when DNS info is available, but it doesn't cause any real delay because the connection couldn't be established anyway until DNS resolution happened.

Now, if a bug exists here, is that Firefox 4 (according to your report) fails to actually abort the initial request on redirection (otherwise the counter wouldn't roll): it gets aborted a bit later than due, when the docshell gets associated to the second request (exactly as it happens when you click on a bookmark when a page has not finished yet to load).

Investigating, thanks...

Glad I was of some use, and thank you for both your patience and your explanations. Also, sorry for all the typos and bad grammar

Mmm, I cannot reproduce on Mozilla/5.0 (Windows NT 5.2; WOW64; rv:2.0b10pre) Gecko/20110117 Firefox/4.0b10pre and NoScript 2.0.9.5

Hopefully it's a bug they already fixed... could you try latest trunk with a clean profile and just NoScript?
Are you by any chance using a proxy?