[BUG] "Disable restrictions for this tab" worded incorrectly

[d3fault]

NoScript 10.2.0

"Disable restrictions for this tab" implies that all scripts, including ones not yet included (recursively), will not be restricted. In the old version of NoScript it was worded "Temporarily allow all on this page" or something, which is more accurate.

Elaborating: After selecting "Disable restrictions for this tab" the page will refresh, but sub-scripts included by the scripts that were just allowed during that refresh... are still blocked.

I'm not saying we should have it one way or the other: imo we should have both! "Disable all restrictions for this tab" (including yet to be referenced scripts (recursively)) _and_ "Temporarily allow all top-level scripts that are currently blocked on this page" (less verbose/wordy tho ofc ).

[therube]

https://forums.informaction.com/viewtop ... ive#p96901

I've long & to this instant am confused by the wording (& icons).

I thought "disable restrictions for this tab" - did just that, disabled restrictions for this tab - totally, recursively, if you will, & for any site at all that is opened - in that tab. (Other tabs are not affected.)

Note that this is a feature that was not available in older NoScript.

But looking now, I'm not sure what it is doing?
Maybe it is...


OK, I see, it is doing as I said.
(It's just taken me some time to reacquaint myself with what to expect after being away from FF & NS10 for so long.)

[musonius]

Until version 10.1.9.9 setting "disable restrictions for this tab" did not block anything for the tab. The presets for the listed sites did not change, however, they just were not applied. With version 10.2.0 setting "disable restrictions for this tab" does not seem to have any effect at all.

[therube]

I didn't have 10.2 in, but putting it in now, it "looked" to be working.
So then I put 10.1.9 back in, & it "looked" to be working.

And then I went to https://www.aldi.us/en/weekly-specials/our-weekly-ads/, & that is not working the sales "specials" are not displaying - this in a tab where "restrictions disabled" (which I'm not sure if that is the case or not).

Normally, well normally with NoScript 5, that page would say, well with aldi.us allowed, but nothing else, "Oops!
This content is blocked by your browser's private browsing or ad blocking. To view this content, please exit private browsing or disable ad blocking for this site.", & that is a sign (to me) that I also need to allow some other domains.

But NoScript 10, with restriction disabled (seemingly), is not giving me the specials?

Don't know if it is 10.1 vs 10.2, something with the aldi site that it is not liking, something with 'disable restrictions for this tab', or maybe something about the sequence of the sites I opened in that tab before getting to aldi.us?

(Allow Globally works.)



(I'm kind of thinking it is the aldi page itself, in conjunction with the 'disable restrictions for this tab'.
And if that is the case, then 'disable restrictions for this tab' isn't .)

[musonius]

I tried the same with Tor browser and there it worked! Maybe there is some problem with my standard Firefox profile. I have to investigate that further.

[musonius]

I can reproduce it. Firefox 63.0.3 and NoScript 10.2.0.

1. create a new profile in about:profiles and start Firefox using the new profile
2. install NoScript from addons.mozilla.org (I did not change anything, just used the defaults, but restarted the browser after installing NoScript)
3. load an article of The Guardian. The sections "related stories" and "Most viewed" need assets.guim.co.uk.
4. set "Disable restrictions for this tab" and nothing happens after reloading the page. Setting theguardian.com and guim.co.uk to Temp. TRUSTED helps though. However, that should not be necessary.
5. unset "Disable restrictions for this tab"
6. go to the options of NoScript and check "Debug" and uncheck it again
7. goto 3. Now setting "Disable restrictions for this tab" works perfectly fine. All scripts are loaded and the sections "related stories" and "Most viewed" are shown as intended.

I am wondering why checking and unchecking the option "Debug" should make it work. When I posted the first comment above I had just created a new profile, installed NoScript and imported my personal settings which I exported from my previous profile. I usually start from scratch when I am starting with a new profile and the first step is checking "Debug", deleting the list of trusted sites and unchecking "Debug" again. This time I did it differently.

[musonius]

I can still reproduce this behavior: disabling restrictions for the current tab does not work until changing some option like Debug or something else like showing the counter, for example. After restarting Firefox it does not work again until I change an option. This is reproducible here on two computers (at home and at work) until I install another extension like uBlock Origin or HTTPS Everywhere. It does not seem to depend on the configuration of NoScript, the default configuration is sufficient.

[therube]

1. create a new profile
2. install NoScript
4. set "Disable restrictions for this tab" and nothing happens after reloading the page.

I can still reproduce this behavior: disabling restrictions for the current tab does not work until changing some option like Debug or something else like showing the counter, for example.

This is reproducible here on two computers (at home and at work) until I install another extension like uBlock Origin

Confirmed.

I'd say we have quite the BUG here.


And to top it off, the lack of change in the in the icon on the permission dropdown after having effected a permission change - but not yet having left the dropdown [even that is not consistent], & then the inconsistency too with the NoScript icon correctly displaying the actual state you're in.

---


(After posting this [from SeaMonkey], & going back to Quantum, I get, "In order to operate on this tab, NoScript needs to reload it. Proceed?". Why)

(Why do I have to go to the guardian to find out about Tommy Robinson?)

[musonius]

Until version 10.1.9.9 setting "disable restrictions for this tab" did not block anything for the tab.

When I wrote that, I did not realize under what exact circumstances the bug occurs. I have tested the bug with version 10.1.9.9 now and could reproduce it. Since I usually use NoScript and HTTPS Everywhere together, everything looked fine. When version 10.2.0 was published, I created a new profile and installed NoScript alone, saw the bug and thought the bug was new.

After testing with version 10.1.9.9 I have more information: The bug is not reproducible after checking the option "Temporarily set top-level sites to TRUSTED". By unchecking this option, the bug can be reproduced again. And I further failed to see that setting "disable restrictions for this tab" does indeed change something: it seems to unblock the top-level site, but blocks everything else.

[musonius]

If the developer utilities are open, "disable restrictions for this tab" works as expected. As soon as I close them, I can reproduce the bug.

Thus, the bug is not reproducible here, if at least one of the following is true:

• Another extension is installed (I tried HTTPS Everywhere and uBlock Origin).
• The developer utilities are open.

If the option "Temporarily set top-level sites to TRUSTED" is checked, "disable restrictions for this tab" reloads the page correctly, but does not work when I load other pages in that tab.