InformAction Forums

NoScript | Options (I guess that's what you call it?), Custom, puts domain in Custom mode regardless of whether you've effected a change or not.

Should it?

And worse yet, those permissions persist (as in a Revoke does not have an affect on them).
So even an inadvertent click of Custom (automatically) changes a domain to Allowed (essentially).


And you're going to say there is a Temporarily Allow Custom.
Well, I didn't even see that.

No, the behavior is wrong, dangerous.

Do you mean you expect a site to be left with the CUSTOM preset assigned only and only if you click some checkbox, too?
I can see the rationale, but

1. the other presets take effect immediately
2. whenever you click CUSTOM, the preset currently in effect gets copied, so you're never giving more permissions than the current until you interact with the capability checkboxs. For instance, if you click "CUSTOM" on a currently UNTRUSTED entry, you get no permissions at all.

However, there's a little caveat to rule #2, which is what you're ranting about last: the "temporary" flag doesn't get copied, hence if you click CUSTOM on a site which is currently TEMP. TRUSTED, you automatically turn it into permanently TRUSTED. Which, at the time I implemented it, seemed like a feature to me: once you choose to customize permissions for a site, you probably want the customized settings to stick.

So, you're probably right: the best course of action would be either copying the temporary flag as well, or making CUSTOM stick only if you actually changed something on top of the copied capabilities.

Giorgio Maone wrote:So, you're probably right: the best course of action would be either copying the temporary flag as well, or making CUSTOM stick only if you actually changed something on top of the copied capabilities.

Both options do not necessarily exclude each other. For example, it makes sense to allow temporary less than TRUSTED, but more than DEFAULT, and one could first click Temp. TRUSTED and then move to CUSTOM to disallow something and still want to have a temporary CUSTOM. The question is, which behavior is most intuitive?

Personally I would prefer the CUSTOM rule to be initiated as TEMPORARY and stay so until manually changed to permanent.

However this might not suit all, so maybe a option for it?

skriptimaahinen wrote:Personally I would prefer the CUSTOM rule to be initiated as TEMPORARY and stay so until manually changed to permanent.

However this might not suit all, so maybe a option for it?

Such option was already requested in https://forums.informaction.com/viewtop ... 10&t=25104