[RESOLVED] NS causes multiple versions of page in Back/Forwa

[Data1001]

This is a bug report, I suppose, as much as anything -- since I will likely be disabling NoScript until the problem is resolved (or something else comes along that I can live with as a replacement -- which is not likely, since I use NS a lot).

Yes, this was an odd one, and I originally asked it on the Mozilla support pages. They directed me to the official troubleshooting method, by which I was able to narrow the culprit down to NoScript v2.1.1.1.

I had this problem with Firefox 4.x -- and I just upgraded to FF5, but the issue still existed.

What happened was, when I surfed to more than one page (or site) on a tab, then wanted to go back, I found that my Back button history often had multiple versions of the most recent page loaded, so that when I pressed the Back button once, it did nothing. Instead, I had to hold the button to display all of that tab's recent history, in order to return to the page that immediately preceded the current page.

Here's an example -- I just tried this earlier tonight.

I opened a new tab.
Typed imdb.com in the address bar.
Clicked on a NewsDesk story: Jon Hamm Locks In 'Mad Men' for 3 Years

URL: http://www.imdb.com/news/ni11982605/

Then clicked on Jon Hamm's name.

URL: http://www.imdb.com/name/nm0358316/

(And come to think of it, IMDb seems to be where I noticed this happening the most frequently.)

So the back button just reloaded the Jon Hamm profile page again, and ditto when I finally paged back to the news story page (took me two clicks of the back button to go to the page before it).

Odd thing, when I repeated this process -- without opening a new tab -- then I had FOUR of the news story pages in the drop down from the Back/Forward buttons, but TWO of the Jon Hamm profile pages.

Ah, here's an interesting thing -- every time I went to a new page (Hamm's bio, for instance), then went back, there was suddenly one more instance of the previous page.

I've seen literally DOZENS of instances of one page loaded up in this Back/Forward drop-down history. Not the ideal situation, obviously.

Hope that makes sense. Just wanted you to know what my issue was.

Thanks!

Here is a screen cap of the problem, if this works...

[Alan Baxter]

Edit: I'm able to duplicate the problem if I allow imdb.com. It also occurs if I Allow Scripts Globally.
NoScript 2.1.1.2rc8
-----------------------------------------------
I'm unable to reproduce this problem using a test profile that has only the most recent version of NoScript installed and using the NoScript and Firefox default settings.
Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
NoScript 2.1.1.2rc7

You may have an extension conflict or corrupt profile. Can you reproduce the problem in a new profile that has only the latest development build of NoScript installed?

[Mad Medico]

I had this same problem on Imdb, (seems to happen with a facebook "share this page" feature) and it didn't come up when I tried what Alan Baxter suggested with creating a clean profile with only the development build of NoScript installed.

[Mad Medico]

After trying out some of the other troubleshooting methods that are recommended on here, I can guess that this is probably an extension conflict

[thom1234aoeu]

Hello!

Great addon, I love it and use it all the time, but:

I have this annoying problem as well and can tell you that, for me, it occurs only when "imdb.com" is allowed using the toolbar button. Disallow that domain and the problem disappears, but instead some functionality, such as the featured content scroller on the front page, is disabled.

Tested with both my main profile and a fresh one with only NS 2.1.1.2rc8 installed.

[thom1234aoeu]

Sorry, I meant to underline "allowed" in that post.

Also forgot to mention that I'm using Firefox 5.

[Alan Baxter]

Yes, I see it now if I allow imdb.com. The problem also occurs if I Allow Scripts Globally. We'll see if Giorgio can fix this.

[Giorgio Maone]

Investigating, thanks.

[therube]

(This appears NOT to be an issue in SeaMonkey 2.1/2.2. SeaMonkey does not use the integrated Back/Forward button like FF.)

[Giorgio Maone]

Should be fixed in latest development build.

[al_9x]

a few questions about executeDOM:

1) when, why and how frequently is documentElement null/undefined?
2) for script insertion is there a difference between documentElement and document.body
3) is document.body perhaps more reliable? i.e. never null?
4) since executeSandbox has performance issues, is there a danger of regression in bringing it back?

[Giorgio Maone]

a few questions about executeDOM:
1) when, why and how frequently is documentElement null/undefined?

Always when called from "content-document-global-created" (Fx 3.6, but only in subframes), never when called from "document-element-inserted" (Fx 4 and above).

2) for script insertion is there a difference between documentElement and document.body

Yes, documentElement the root of the document (<html> in HTML documents) and is always guaranteed to exist when the first content script is executed, while document.body is not (think of framesets, for instance).

3) is document.body perhaps more reliable? i.e. never null?

quite the opposite, see above.

4) since executeSandbox has performance issues, is there a danger of regression in bringing it back?

Not in Fx 4 and above, maybe in Fx 3.6 (even though Sandboxes are created for iframes only).

[al_9x]

a few questions about executeDOM:
1) when, why and how frequently is documentElement null/undefined?

Always when called from "content-document-global-created" (Fx 3.6, but only in subframes), never when called from "document-element-inserted" (Fx 4 and above).

For "content-document-global-created" did you mean 3.6 and above? Otherwise you appear to be saying that it's never null in >=4.0, but isn't reintroduction of executeSandbox intended to to fix this history bug in 5.0 (if not then why)? So then it must be null sometimes?

And as to the why, is it a gecko bug?

[Giorgio Maone]

For "content-document-global-created" did you mean 3.6 and above?

Nope.

Otherwise you appear to be saying that it's never null in >=4.0

Yes, it's what I'm saying.

but isn't reintroduction of executeSandbox intended to to fix this history bug in 5.0

No it's not.

(if not then why)?

Because the alternate location-based method appears (as shown by this bug) to cause undesired effects on history when used at an early stage of page loading, so we want to avoid it no matter how/if it was/is actually reached.

So then it must be null sometimes?

It was, but because of another bug (whose fix you didn't notice because your analysis was too much focused on the ScriptSurrogate.js file).

And as to the why, is it a gecko bug?

Not a gecko bug, but a NoScript bug created by a recent Gecko change which went unnoticed until Fx 5 has been released (hint if you're looking for it: during "document-element-inserted", document.defaultView may be null or undefined).

[Data1001]

Giorgio et al --

Thanks so much for the replies. The latest development build does indeed seem to have solved this problem. I appreciate it!

Very happy to be able to use NoScript again!