[RESOLVED] Functionality of allowWhitelistUpdates changed?

[barbaz]

Well what I would try in this case is before installing NS go to about:config and create a boolean pref named noscript.firstRunRedirection with a value of false
(on the about:config screen, right-click > new)

[GuestPassingBy]

Good call. Partially caffeinated brain sees that workaround now. This is why you shouldn't do things when you are tired. I reported a bug I could have used to break forced whitelist updates. Darn it!

[barbaz]

Er, I was just making a wild guess... did that actually work?
(And this is still a bug either way.)

Can you please post here a link to this Firefox Portable in case whoever tries this next can't reproduce the problem on "regular" Firefox/SeaMonkey?

[GuestPassingBy]

I don't think you need to use a portable to see this, but if you want to: http://downloads.sourceforge.net/portab ... sh.paf.exe. If you want to go through the whole process, also download the NoScript 2.6.9.29 and NoScript 2.6.9.30 XPI files.

Install Firefox, then disable your Internet connection, then install NoScript 2.6.9.29, then install NoScript 2.6.9.30, then examine the whitelist for missing updates. I believe they will be missing due to onVersionChanged not being called when you installed NoScript 2.6.9.30. I believe that is because the noscript.version pref was set to an empty string after you installed NoScript 2.6.9.29. I believe that is due to the way the code works and your not having an Internet connection when you installed NoScript 2.6.9.29.

For reference, we can look at NoSCript 2.6.9.30, noscriptService.js:

Code: Select all

7029: const ver =  this.VERSION;
7030: const prevVer = this.getPref("version", "");            <------------------
7031:
7032: if ((this.firstRun = prevVer != ver)) {
7033:     if (prevVer) try {                                  <------------------
7034:       this.onVersionChanged(prevVer);                   <------------------
7035:     } catch (ex) {
7036:       Cu.reportError(ex);
7037:     }
7038:     this.setPref("version", ver);
7039:     this.savePrefs();
7040:     const betaRx = /(?:a|alpha|b|beta|pre|rc)\d*$/; // see http://viewvc.svn.mozilla.org/vc/addons ... arkup#l431
7041:     if (prevVer.replace(betaRx, "") != ver.replace(betaRx, "")) {
7042:       if (this.getPref("firstRunRedirection", true)) {  <------------------
7043:         const name = "noscript";
7044:         const domain = name.toLowerCase() + ".net";
7045:
7046:         IOS.newChannel("https://" + domain + "/-", null, null).asyncOpen({ // DNS prefetch
7047:           onStartRequest: function() {},
7048:           onStopRequest: function(req, ctx) {
7049:             if (req.status && req.status !== NS_BINDING_REDIRECTED) {
7050:               ns.setPref("version", '');                <------------------
7051:               ns.savePrefs();
7052:               return;
7053:             }

I hope this is an accurate report.

[Whitelister]

Some more idle thoughts. Sorry to be late to the thread.

I'm thinking that NoScript doesn't have a way to reliably determine whether an entry is "user owned" or "developer owned".

The Addons Manager would have to be the biggest load of allow/forbid/install/don't install dialogs known to man, so one more isn't going to fuss the default install user - much.
LIST: whitelist changes - - accept?
Annoyed default users could be given a toggle for the confirmation dialog - along the lines of "always accept NS default whitelist updates"

I, personally, am slightly concerned about a developer pushed removal of something I want to be on the whitelist, but I'm not very concerned.

+1. It's the additions that have much more capacity to subvert user intent. In unknowable ways.
And it's unfair to treat the non-power user as a member of an amorphous dumb bunch
A user may toggle a whitelist entry deletion on-the-fly for many reasons. The developer has designed NS's default menu domain hierarchy for user access to the whitelist without high levels of knowledge of domain levels. And many intermediate users do toggle domains on-the-fly to find a least-number solution.
Given the size of many site's NS menu entries, it'd be hard to expect any user to make a whitelist inspection at update if they can't exactly remember the site they deleted to prevent some unwanted effect.
Far better for NS to alert this kind of user that previously unwanted functions may be restored by whitelist updates; the user is then prepared for more directed troubleshooting in the worst case, and for the decision to take more responsibility for whitelist populating at best.