InformAction Forums

I have several people who use this computer. To make sure that one of them does not disable or remove certain desired Firefox extensions, those extensions are globally installed. No Script happens to be one of them. One thing I have noticed, is that if I do not un-install the older version of No Script before installing the update, the version number as reported by MR Tech's Local Install, does not reflect the new, updated version.

I have posed this question to Mel, and have not received any reply. What I do notice, is that after un-installing the old version (and restarting Firefox); No Script is no longer shown as an addon.

Globally installing the new version, and starting Firefox will result in FF downloading the "What's new" page, indicating that i have upgraded from old version to new version.

Obviously, some of the information remains behind, because I still have my white and black lists. So, I have to ask, any idea of what is going on??

The version number as checked internally by NoScript to show the what's new page, like your whitelist and other settings, are stored as preferences, which are profile-specific and persistent across upgrades/removals.

I always had problems with updating a globally installed noscript (by using the "-install-global-extension" parameter), therefore I switched over to unpacking the xpi file manually. Seems to work without problems.

@Giorgio,

Thanks for the information. I figured that No Script has two components, like many Firefox extensions, one for the users preferences, and one for the core executable.

@dhouwn,

I think I am going to create a couple of test bed set ups, and see exactly what is going on. I have this script that does all of our global installs, and I do not need an "exception rule". PS, I use a similar set up at my employer for exactly the same reasons.

You have no idea how many times using this technique (global installs) has prevented someone from downloading malware.

Today, I received notification that version 1.9.1.9 was available from addons.mozilla.org. I did have 1.9.1.8.

I downloaded the new version, and globally installed it using my typical script, and re-launched Firefox. As expected, the version number did not change as reported in the "Addons" window.

I browsed through "about:config", and examined all "no script" related preferences, and spotted one user set preference, noscript.version which was set at 1.9.1.8. Changing it to 1.9.1.9, and re-starting Firefox caused the "home page" indicating an upgrade had taken place.

What is kind of funny about this, is that only one profile had the preference changed, and none of the others picked up on it (as they should because it is "supposedly" globally installed).

Makes life interesting.

Any ideas?

I noticed something slightly weird too but I assumed since I had the dev build of x8 and when official x9 was released somehow it didn't reset right. Reinstalling the extension without removing it and restarting Fx fixed it with no unusual side effects.

Well, I just had an interesting experience. I got the update notification about the availability of an update, and downloaded 1.9.1.91. Using a profile I consider a "control" profile (it is where I keep bookmarks to the download locations at addons.mozilla.org); I uninstalled version 1.9.1.9, and restarted Firefox.

I then displayed all 'noscript' about:config entries, and found only user set preferences. One of them being the version number 1.9.1.9. I then globally installed both no script and an updated version (1.0.2) of ad blocker. Interesting, no script displayed the new version 1.9.1.91; but ad blocker did not, as the version number from the old version was shown (1.0.1). Both addons were shown as installed today. Just for the heck of it, I uninstalled ad blocker, and restarted Firefox, which now did not show ad blocker as an installed addon. Then I closed Firefox, and then globally installed ad blocker (again), and re-started Firefox; this time, the updated version number was shown.

The curious thing, is that the version number for both ad blocker and noscript are user set preferences. My question is "Why?"

This could end up being a Firefox global install bug! I think I am going to peruse the support forums at mozilla and see if a bug report has been entered.

Yes this is a user set preference as the developer of the addon has to update the internal numbering. I think your problem is something that has happened to pretty much everyone during an addon update or installation where it gets corrupted or stuck and a reboot fixes it and at worst a reinstall. Anyway glad its working for you now.

It only works in the context of an un-install, restart, and then an install of the update.

What I guess I am trying to say is that the mechanism to update globally installed extensions does not seem to adjust the version number. So, is that an extension problem, or a global install problem?

I believe that would be a global install problem, although if the extension is not properly playing, it could cause issues too.

dhouwn wrote:therefore I switched over to unpacking the xpi file manually. Seems to work without problems.

UPDATE: Since I moved the Firefox installation folder to %ProgramFiles% I'm also having the issue of Noscript not updating it's version number.
It's probably due to the fact that all the content of the %ProgramFiles% folder is read-only by default for non-admin users in Vista.

I can not speak for the issues you have with Vista(ster) [sorry, but I can not resist!!! ]; as I am an XP user.

I do not install ANY of my applications in %ProgramFiles% because, I knew someone who had his %ProgramFiles% sector on the disk get flaky, and of course, he did not back up the hard drive. I am not about to let that happen to me. I install applications in 3 separate folders, one called APPS (that is where I hide Firefox and Thunderbird amongst others. The other folder is called TOOLS; I think what goes there is obvious (it is where I hide wireshark). The third folder is called ZANGO, (named after the infamous purveyor of malware); and that is where I hide Spybot S&D, my firewall, AdAware, etc. I have seen so many people's computers with a ton of folders in %ProgramFiles%; to me a disaster waiting to strike.

I have found that other extensions (but apparently not themes) are also subject to this behavior. I have decided to keep a list of them in the same folder as the scripts that are used to globally install extensions. Each time one of them is updated, I guess its uninstall, restart, and finally install the update. I hate this workaround, and it does not make my life any easier. But then again, who said that working with computers would be easy. I should have realized a long time ago (1970) that computers are indeed quirky. That lesson was trying to figure out why two names in a sorted list were out of sequence in a FORTRAN class project.

I am not sure if there is going to be a fix for this. From what I have seen, global installs are at the bottom of the Mozilla dev teams priority lists. And that is shame, because, it may very well be one reason why corporate adoption of Firefox lags.

(Side note, I ran this through a spell checker, and the suggested replacement for "Mozilla" was 'Godzilla').

dhouwn wrote:

dhouwn wrote:therefore I switched over to unpacking the xpi file manually. Seems to work without problems.

UPDATE: Since I moved the Firefox installation folder to %ProgramFiles% I'm also having the issue of Noscript not updating it's version number.
It's probably due to the fact that all the content of the %ProgramFiles% folder is read-only by default for non-admin users in Vista.

Fatman's colorful post not withstanding, everything in %ProgramFiles% is indeed in read-only mode (even as an admin). However, if you have admin privilages and try to access it, it will give you elevation privileges and if you don't have them, then you can read but not touch and in some cases no access. As for writing data/files back to %PF%, even with admin privileges, if the app is not running in admin mode, most if not all of the new and modified files are written to VirtualStore instead of the actual %PF%. Some applications are developed better and have dynamic UAC management that can handle prompting for permission changes but those that don't just get written to VS.