InformAction Forums

I installed the 1.9.4.9 dev build and I have noticed that on several HTTPS sites, the images fail to load and show broken. Now if you load them in the URL bar directly, they load fine but not on the page and no matter how many times you refresh and they are whitelisted sites. Logging out and closing the tab and trying again "usually" loads the image, this is very reminiscent of the HTTPS image from cache issue that was apparently resolved a while back. It seems to be back again.

Also, I have encountered two sites today, one of them is a web proxy (proxify) in which it shows JS is disabled and there if no functionality, despite the site being whitelisted, there is no sub-url or reference shown or needed either. In one case, closing Fx after permanent whitelist and restarting fixed the issue but NOT the other and definitely not when its temporarily whitelisted, what's the issue here?

Here are screenshots showing lack of JS while showing NS is whitelisted.

Looks to be another one.
Same sort of symptoms. Clicked an "external" link (from an "HTML aware" text editor). URL is shown on Location Bar, but status shows "Stopped", & page never loads.

At the end of the day today, I noticed that I had a hung SeaMonkey processess, so that may have contributed to what I saw. But then I don't know when it manifested itself? Could have been there a for a long time (days)? Didn't think at the time to see if it was a SeaMonkey 1 or SeaMonkey 2 seamonkey.exe. If it were a 2, then it wouldn't have mattered cause I was running 1.

-------

This was NoScript 1.9.4.6, SeaMonkey 2, Intel, from the 23rd.
Wasn't doing a whole lot. Memory was manageable, 218MB, spikes still there about 8% but seemed inconsequential.

http://i40.tinypic.com/df927p.jpg

Then as I was closing down windows, memory dropped to 167MB, spikes still there but to a lessor degree, around 5%.

http://i39.tinypic.com/33a5ow6.jpg

No surprises (& without really pushing SeaMonkey 2 yet) I have to say my earlier issues (not releasing memory) seem resolved at the 1.9.4.6 level.

I get a broken https: at https://proxify.com/.

Are you logged in at proxify?

I see nothing alerting me as to the status of JavaScript?
I do not see the string, "This site needs JavaScript"?

The site (without logging in) appears to work for me without enabling JavaScript.

Maybe I have the wrong "proxify"? URL?

therube wrote:I get a broken https: at https://proxify.com/.

Are you logged in at proxify?

I see nothing alerting me as to the status of JavaScript?

The site (without logging in) appears to work for me without enabling JavaScript.

Maybe I have the wrong "proxify"? URL?

1. Go to: http://proxyfy.com/
2. Enter a url to whatever, the user was trying: http://newpersepolis.myminicity.com/
3. You will get the first screen shot I posted on the next page (which happens to be: https://proxify.com/p/011110A0000110/ht ... ity.com=2f) and that's even with the site allowed

Additional bizarreness with the NS icons and stuff too. You can see in this screenshot, that the site is whitelisted but the icon is wrong and the tooltip is also wrong. Something is definitely wrong.

I got an XSS:
& when I Unsafe Reload ...

Then I do get the JavaScript message you displayed whilst proxify.com is whitelisted.
Now if I start with the https: URL initially (& other then the broken https: warning) & get none of that & it appears to work fine.

Someone has a typo ...

from [http://proxyfy.com/]:

OH, you have a typo? Do you? Or is that something intentional?

No typo, its correct. Proxyfy.com and it routes to Proxify.com, there is also proxify.net, .org, .biz and etc etc.

And what happens if you whitelist Proxyfy.com?

With proxyfy.com AND proxify.com both whitelisted, it works.

For the purpose of trying to figure this out, Proxyfy.com, Proxify.com, Proxify.net has all been whitelisted, makes no difference. The endpoint, the site I listed earlier was even whitelisted, just in case it has something to do with it.

(First Revoking my Temporary Allows ...)

When starting with the http://proxyfy.com URL, whitelisting that looks to be all that is needed.
Once I do that it works, rolls over to https://proxify.com/ without complaint (other then the broken https icon), & loads my selected site.

So from what I see, that is all I need on my end.

(Some screwy domains that they have.)

Or you can start with https://proxify.com/ & forgo whitelisting altogether.

OH, & if you use a site like http://www.whatismyip.com/ to "proxify", you will see that whatismyip.com returns a proxied IP, not your actual IP.

Well that's an interesting finding because that is NOT what's happening here, but then again you are on SeaMonkey right? Might be something malfunctioning with NS that is affecting Fx installations. Just thinking out loud on that one, not sure, just the only difference between yours and my installations that I can think of at the moment.

Thinking it's something on your end.
Just tried it on FF 3.0.10 & it worked as I described.

Create a new Profile, install NoScript & see what happens.

OH, & you do have chrome: specifically whitelisted (it seems). See if that matters. (IOW, try a Reset.)

The chrome only showed up because I used screengrab to capture the screenshot and that requires chrome, not there otherwise.

Ok, in addition to the HTTPS broken image issue and the connection failures until reboot after whitelisting, now there is an issue that if you temporarily whitelist an iframe, nothing shows. The only way to make it work is to permanent whitelist and restart Fx, which is totally defeating the principle of temp allow/disallow on the fly. Hopefully while we are sleeping on this side of the world, Giorgio can let me know what he thinks is going on or possibly even have a fix for me to try tomorrow.

URL?

URL = http://djeault.blogspot.com/2007/02/iframe-test.html

URL = http://www.nicky.net/4images/iframe.html

Both working as expected here.

With the second site, you need to Allow the IFRAME 3 times (but that is expected).

Did you ever try that new Profile?

@GµårÐïåñ:
I'm still trying to reproduce.
I've got no doubt you're on some issue, but I'm not sure it's from NoScript (alone, at least).
Can you try on a clean profile (as therube suggested), and if it works try Standard Diagnostic?
If you're using Request Policy, my best bets are on that one. 2nd line, ABP.