[RESOLVED] Possible bug in new version 1.9.7.7

[RH]

I'm developing a website using a locally installed apache server to test "on the spot" so to speak. I just allowed an update of NoScript to version 1.9.7.7, and upon restarting I find the elements of my website are not rendering properly. Since I was in the process of working on the site, I first thought I had made a typo or other error that caused the problem. After testing, and ultimately disabling Noscript, I'm positive the problem is with Noscript and occurred as of 1.9.7.7.

The problem occurs:

• When I view my site locally in Firefox using localhost or 127.0.0.1 with NoScript 1.9.7.7 installed and enabled.

• When I have allowed scripts from localhost and 127.0.0.1.

The problem does not occur:

• When I view the site from the "real" host.

• In other browsers. I tested IE8, Chrome, Opera, and Safari.

• In Firefox when I disable the NoScript addon.

• When I used a NoScript version prior to 1.9.7.7.

• When I render the page with localhost/127.0.0.1 forbidden.

Because the issue seems to do with accessing localhost while noscript is running, I have no way to offer a link to illustrate the problem. The javascript has been thoroughly tested and debugged and appears to be valid. The XHTML and CSS all validate as well. The problem seems to only affect an areas of the page that are hidden with document.GetElementById('container').getElementsByTagName('span').style.display='none', then revealed again with document.GetElementById('hm1').style.display='block' upon a mouseover. What appears to happen is that all elements within the once hidden element appear to be stacking directly on top of each other as opposed to in rows like good little divs. I have tried changing the tags used from span to DIV, which basically disabled the script that acquired elements by tag name "span". The result is that the elements don't collapse once the page loads, however they do collapse and render properly using document.GetElementById('hm1').style.display='block' and document.GetElementById('hm1').style.display='none'.

I'm not sure if this is a side effect of a new feature or a bug, but it's going to make web development difficult for me. I can switch to another browser as my default, however I will still need to be able to reliably test in Firefox. To do this I will have to not just allow all scripts from 127.0.0.1 or localhost, but disable NoScript entirely. I'm also a bit concerned that this is an unintended side effect that could manifest in other ways.

I've included all the relevant details that I can think of, but if you need more information post a reply and I'll try to help.

Key elements to producing the glitch:
NoScript 1.9.7.7
getElementsByTagName
locally hosted Apache website (Localhost or 127.0.0.1)

RH

[Giorgio Maone]

1. Does this problem persist with latest development build 1.9.7.8?
2. If it does, can you see any NoScript or ABE related message in Tools|Error Console?

[Fallen Petal]

Hi,

I think I have the same issue. I put together a stripped down test case. You may want to copy the html to localhost to reproduce reliably. Note that no javascript is used, just in-page css.

EDIT: link removed because files deleted from server (because issue is resolved)

It's very odd behavour, sometimes it only affects some places and not others on the same page with the same code. Refresh then maybe one, none or all of then will work. Rarely also occurs on non-localhost.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008122011 Firefox/3.0.1 (Debian-3.0.6-1)
NoScript 1.9.7.7

Occasionally this ABE error occurs, which prevents reloading the page with F5:

[ABE] <LOCAL> Deny on {GET http://localhost/testcase.htm <<< about:blank, about:blank}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny

Disabling ABE does seem to have resolved the issue, will post back if I still have probs with ABE disabled.

Oh and thank you for this great open source product!

EDIT: Ok I actually did what you asked and tried the dev version 1.9.7.8 and it seems to be fixed with ABE enabled again

[RH]

I just tried the development build you linked and it seems to have resolved the problem in my case. I didn't check the error console prior to updating to the dev build, but I checked it after and saw no errors. If it would help, I could roll back to 1.9.7.7 again and check for errors; however as it appears that whatever is wrong will be corrected in the next release, I will wait to see if you deem it necessary. I'm happy to help if you need it, just let me know.

Thank you Fallen for providing a test case. When I found the problem I was a bit tired and had the motivation to post my message, but not enough to create a test page to actually narrow the trouble down further or even illustrate the problem. I'm glad I was able to at least explain the symptoms well enough that someone understood what I was getting at. I thought for sure the problem required some javascript to reproduce, the fact that you did so with only css was a surprise. Then again I didn't know you could make a dropdown menu with only css...I might have to rethink my design a bit now if you don't mind me borrowing from your example.

Thank you Giorgio Maone and Fallen Petal for your input on this issue, I'm amazed by the response time as I only posted a few hours ago. I'm a big fan of NoScript, and wanted to post about my problem not just to resolve my immediate need but to hopefully give something back to the makers of the best Firefox addon ever.

[RH]

*update*

I just checked out my website at it's "real" hosted server using another system with noscript 1.9.7.7 installed. The layout problem occurred again. What's significant this time is that I wasn't loading the page from my local apache server but from the real host. This means the problem isn't limited to localhost or 127.0.0.1 as I thought previously, it includes the the real inter-nets. I'd say it makes the problem more serious if it is going to affect the average noscript user. Also, as Fallen Petal demonstrated, the problem can be reproduced without the use of any javascript. It seems to impact CSS pseudo classes just as it does javascript/DOM interaction.

I'm left wondering why the dev build seems to fix the problem. Does it mean developers are aware of the issue and a solution is already implemented in the next release?

RH

[Giorgio Maone]

I'm left wondering why the dev build seems to fix the problem.

No, you're not.

Does it mean developers are aware of the issue and a solution is already implemented in the next release?

It usually means this,

v 1.9.7.8
=====================================================================
x Fixed invisible links detection turning some links into absolutely
positioned if they have no layout on load (thanks dpmccabe for
reporting)