BUG : Noscript empties URL bar and displays blank page

[maathieu]

Hello Giorgio and first of all thanks for this wonderful piece of software that is Noscript.

Here's my humble contribution: a bug report!

I use Noscript very conservatively (everything javascript blocked by default, with manual activation of javascript per subdomain-basis). My setup is Noscript 2.6.9.26 with Iceweasel 31.6.0 on Debian Stable Jessie.

I have kind of spotted a weird bug lately which baffled me for a while: sometimes after activating javascript, Noscript would reload an empty page instead of the website I was consulting, leaving the URL text field "blank."

I have set up a new Iceweasel account to test this, in order to make sure there are no weird interactions with other extensions/plugins I may use, so this should "work" on any vanilla Iceweasel/Mozilla+Noscript.

The bug gets triggered when you have configured Iceweasel with the startup option to display the tabs that were opened during the previous session. Click on one of the tabs that were previously opened, click on the "Noscript" icon to activate or desactivate javascript for one of the page's subdomains. Click on "activate Javascript for whatever.com" and voila:

For some reason, instead of reloading the page, it just shows a blank page. It also empties the URL text area.

However, it works perfectly fine for all new tabs you might open during the current session. The bug triggers only for tabs restored from the previous session.

So, that's it . If you need more info or some more precise test cases or logs, don't hesitate to contact me.

Cheers,

maathieu

[barbaz]

Does it happen for you in Firefox 31 ESR or is this Iceweasel specific?

[therube]

If it happens while Session Restore is still reloading the session, then I may have seen similar, at times.

And in particular if you "force" load an otherwise unloaded (i.e. the tab did not originally have focus) tab, while session restore was still doing its thing.

If it happens after the session has been completely loaded, that I have not seen.

[barbaz]

If it happens while Session Restore is still reloading the session, then

... it might be expected behavior (at least, as things are now) due to the way the browser does session restore?
Wonder if the browser updates some of the document contents before updating the document URL, i.e. part of it thinks you're on about:blank and part of it thinks you're on the URL you think you're on, so when you change permissions and NoScript reloads the page, NoScript thinks it should reload about:blank for you?

Even if that is the case I'd still consider it something that merits a work-around if possible, most users wouldn't think like that.

[maathieu]

Yes, I just tested on Firefox 31 ESR (Linux x86_64 version). It behaves the same way.

I suspect indeed it is related to the way Firefox restores tabs. However it happens even if I set Firefox's cache size to "0" and restart it, so it seems not to be cache-related. It is actually weirder than that: Noscript actually seems to be setting the page's URL to about:blank in the scenario I tried.

Please try the following. Start firefox with a bunch of restored tabs. Go to any one of them, press "Ctrl+U" to display the source code of the page. The source code will show.
Go to another one, click on the "noscript" icon, do not change anything about the javascript parameters, click back on the page content itself to hide the dropdown menu, press "Ctrl+U": Firefox will now try to show the source code for about:blank

Weird stuff...

[Rollo]

I can confirm on debian X86_64, with firefox 31.7 (binary tarball from mozilla ftp site), I can't test iceweasel 31.7

1) New clean profile
2) Install noscript 2.6.9.26, leave all the defaults settings - restart firefox
3) Set firefox to restore tabs from previous session - close firefox
4) Start firefox and go to, just an example: forums.mozillazine.org
5) allow scripts (actually, middleclick on the noscript icon), wait for reload and then close firefox
6) start firefox, after the tab is reloaded allow scripts (again, middleclick on the noscript icon)
7) the tab reload in "blank" as reported by maathieu

Nothing in the browser console: wipe everything before allowing scripts as in point 6 (EDIT: point 6 instead of point 5) , and nothing show up.

No problem with iceweasel 38.0.1 and seamonkey 2.33.1

I tried an old version of seamonkey (2.26.1), and the bug is reproducible.

[barbaz]

Hmm. Did this happen with older versions of NoScript? If not, can you please find the last rc build that worked?

Old NoScript @
https://addons.mozilla.org/addon/noscript/versions
*or*
https://noscript.net/feed?c=100&t=a

In the meanwhile, I'll see if I can reproduce this on any of the Linux machines I've got.. hopefully it isn't a Debian specific problem.

[Rollo]

This is what I have find:
NoScript version 2.6.9.22.1-signed works fine in firefox 31.7 - the bug is not reproducible
NoScript 2.6.9.23rc1/NoScript 2.6.9.23rc2/NoScript 2.6.9.23rc3
Unable to install:


NoScript 2.6.9.23rc4 : the installation goes fine and the bug is reproducible, still nothing in the browser console.

Didn't test with seamonkey

[maathieu]

Yes, I thought it was a regression as well. I've been using tabs for, like, forever and the problem only showed up very recently. Am happy that at least one other person could reproduce it . I'll give it a try with older noscript versions as soon as I can.

However if it is not reproductible in FF38 then it might not be a noscript bug? Still it's going to be annoying for those who are stuck with older versions, such as people using Debian "Stable" Jessie...

[barbaz]

I can confirm the problem in Lubuntu 14.04 / Firefox 31.7 ESR FWIW.
Doesn't even have to be an allow, any restored tab / any changed NS permission will do.
Here's another set of STR from clean profile:
1) close all tabs except about:home
2) go to Tools > Add-ons > Extensions
3) switch back to the about:home tab, go to https://noscript.net/getit#devel, install NoScript latest development build. Restart Firefox
4) switch to the tab that has https://noscript.net/getit#devel open and Forbid noscript.net

After step 4 that tab navigates to about:blank. Clicking the "Back" button, followed by clicking the "Forward" button, brings you back to https://noscript.net/getit#devel.

However if it is not reproductible in FF38 then it might not be a noscript bug?

Maybe not... but NoScript supports Firefox 3.0.9 and later so anything "buggy" happening on Firefox 31 ESR caused by NoScript is potentially fair game for a fix or workaround.

[Rollo]

This time I tried old Firefox releases, with the STR from barbaz: the latest release
showing the bug is 35.0.1, while version 36.0b1 (I mean: 36 beta 1) seems ok.
Hope this help.

@maathieu
When 31esr will reach end of cicle, I think jessie will switch to 38esr.
But I have no idea when...

If you want the "release" iceweasel version, instead of the "normal" esr:
http://mozilla.debian.net/

The pkg-mozilla-archive-keyring package is already in the repository, so
no need to download and install a deb package via http.

I'm running jessie too...