Status Icons Are ALL Wrong

[GµårÐïåñ]

Giorgio, I know we have reported this and you said it was fixed in latest dev release which became formal release and according to the site you don't have another dev build pending but the status icons are all wrong. Figured I give another heads up in case you consider it resolved and need to know it still exists and if you already know then sorry for the repeat but since you've been silent on the more recent reports I figured you might not know or think its still the same.

When you go to a site that has been fully allowed or partially allowed via the menu, the icon in the status still shows blocked and full red. On some sites, it could be completely marked untrusted or mixed and it will show a fully allowed status icon and full white. So not sure what's going on, but the latest build did NOT fix this, so now you know that its actually wonkier than it was before.

[Tom T.]

+ New "partially allowed subcontent" icon to indicate that the top
site is blocked but some active sub-content (e.g. plugin objects
or frames) is enabled.

v 1.9.1.9
x Fixed notifications reporting "Partially allowed" on fully allowed
pages

I would respectfully repeat my original suggestion, which IIRC would be implemented in 1.9.1.8, for the *opposite*: A partial-red (partial-block) icon when the site is allowed, but some sub-content is blocked. As you know, (sadly) Yahoo Mail started using iFrames for attachments. Below, I am attempting to upload an attachment, but have not yet allowed the required object. But although the objects are blocked, please note that the logo is all blue. This was the change I had suggested -- change the logo to part red for all such blocked objects, all browsers. I think *this* confuses many users. Thanks.

btw, should this be moved to NS Development or Support, to see what issues/feedback the public is having?

[Alan Baxter]

I would respectfully repeat my original suggestion, which IIRC would be implemented in 1.9.1.8, for the *opposite*: A partial-red (partial-block) icon when the site is allowed, but some sub-content is blocked. As you know, (sadly) Yahoo Mail started using iFrames for attachments. Below, I am attempting to upload an attachement, but have not yet allowed the required object. But although the objects are blocked, please note that the logo is all blue. This was the change I had suggested -- change the logo to part red for all such blocked objects, all browsers. I think *this* confuses many users.

Ditto with my continuing agreement with Tom's original suggestion. Perhaps it's incorporated in 1.9.1.9, but we know 1.9.1.9 still has status bar icon bugs, as reported by me and the OP. Maybe Tom's suggestion here has already been incorporated, but hidden in the problematic implementation.

I also agree this thread should be moved to NS Development, which is explicitly described to be for reporting and discussing bugs.

[GµårÐïåñ]

Sorry Tom, after reading Alan's post I already moved it.
Additional note, the new update fixed my status icon problems so far, I am still keeping an eye out just in case it pops up again but thanks to Giorgio it seems 1.9.1.91 fixed it.

[Tom T.]

I saw that and removed my obsolete post about moving it. Thanks. The issue I described is still present in 1.9.1.91.

@ Giorgio and all: Until the happy day when we get per-site permissions for such objects, I not only have to allow the *@http://attach.mud.mail.yahoo.com (the exact name/address of this object varies from time to time), but then to reload the page and click "OK", then I can click "Attach files" successfully. "Reload when permissions change" is already in effect. Unless I'm missing some other way to do this (if anyone knows, please let me know), then could the "Reload" be sensitized to reloading on sub-objects like this, so the process would be more automatic? Otherwise, I think we need a very specific instruction set added to the FAQ for "How to attach in Yahoo Mail", possibly with screenshots.

'"NS FAQ 3.7"
Notice that if you've got NoScript Options|Advanced|Plugins|Apply these restrictions to trusted sites as well checked (not the default), you'll need to use Blockable Objects|Temporarily allow *@http://216.xxx.yyy.zzz instead.

+ Specific "clickjacking" countermeasure working on non-whitelisted
pages by default even if "Forbid IFRAME" is not checked: all plugin
objects and frames are forcibly rendered opaque when embedding page
is not in your whitelist. If you want to protect whitelisted pages,
the best protection is still checking "Forbid IFRAME" together with
"Apply these restrictions to trusted site as well" in the Plugins
options panel (thanks Sirdarckcat for brainstorming)

I'm following the recommended advice (full lockdown), so the "Auto-reload on sub-object permission" choice or default would be very useful, and would make the process less user-intensive for novices. Thanks.

[GµårÐïåñ]

Yes I see what you are saying there and I have this issue on a couple of sites too but have just lived with it so far, it would be nice to have the auto-reload on sub-object permissions too. I just assumed my configuration was preventing that, I guess not