Scripts are installed automatically even when that option is unchecked #1647

mjh563 opened this Issue Sep 30, 2012 · 5 comments


None yet

2 participants

mjh563 commented Sep 30, 2012

This is the same as Issue 1636, which I thought had been fixed in 1.3. It's still happening though.


  1. Ensure that "Automatically install updates when found" is unchecked
  2. Update a script
  3. Go to Add-ons Manager and select "Check for updates"

Result: The script is installed automatically, even though the option was unchecked.

arantius commented Oct 1, 2012

Right now, this is WAI, but we might want to discuss the design. What this checkbox means right now (regardless of the exact wording on the label) is that it won't do background updates. If you specifically indicate "I want the script updated" then it does it.

mjh563 commented Oct 1, 2012

Ah, okay. Maybe Greasemonkey should take the following option into consideration then, when deciding whether to auto-update a script: "Update Add-ons Automatically" (in the AOM menu).

I have that option unchecked, because I specifically don't want any add-ons to update automatically. That includes user scripts, because from a user's point of view, user scripts are now just another type of add-on.

So I think that when that option is unchecked, scripts should never be automatically updated, regardless of the update setting in GM options. In other words, that global setting for updating add-ons should override any GM-specific setting.

Only when "Update Add-ons Automatically" is checked should the GM-specific setting then be used.

I believe it's controlled by the following about:config entry:


If that's set to false then IMO auto-updating should never happen. Checking for updates is okay, but not auto-installing them.

arantius commented Oct 1, 2012

In general, I agree with you and so I need to spend some time reconsidering this. I agree that (and have intentionally been trying to encourage thinking towards) user scripts are just another add-on. So one important thing to check is how extensions (the canonical add-on) act.

But where we are now is that I interpreted "automatically" as "silently in the background", and viewed the user actively asking for things to be updated as a separate case. I need to check how add-ons behave in a similar case. And maybe consider removing this Greasemonkey specific option if a generic add-on setting already handles it.

mjh563 commented Oct 1, 2012

Yes, the "Check for updates" option just checks for updates. Whether any updates are then automatically installed or not is an entirely different issue (controlled by the setting I mentioned in my previous reply).

Updates that are not installed are given an "Update now" button and added to the "Available updates" tab, and the user can then install them manually.

These bugs may be of interest:

arantius commented Oct 4, 2012

Updates are a tricky issue that have proved to be controversial. As best I can tell now (please help correct me if wrong, I'm not super confident), standard Firefox behavior is:

  1. Update checks are always made automatically/in the background.
  2. Found updates are automatically installed (by default).
  3. The user can change a setting so that 2 doesn't happen, globally.
  4. The user can change a setting so that 2 doesn't happen, per add-on.

And there's some complex interaction between settings 3 and 4. Greasemonkey is more complicated because people's opinions have made us try to both control whether the checks are made, and whether the installs happen. And so we're both confusing, and out of sync with normal Firefox behavior. At this point once I'm confident I know what Firefox does, I'm just going to emulate it as closely as possible.

@arantius arantius added a commit that closed this issue Oct 4, 2012
@arantius arantius Fix script auto-updating.
The goal is to act just like Firefox acts for any other Add-on.  Using the same preferences it already defines.
This is done by removing all custom "check for updates" code (which previously supported Firefox 3), relying instead on the AddonManager interface.

Refs #1646 (probable fix)
Fixes #1647
@arantius arantius closed this in c932a6e Oct 4, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment