Closed Bug 586574 Opened 14 years ago Closed 14 years ago

Provide way to set a default for automatic updates

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla2.0b7
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: Unfocused, Assigned: Unfocused)

References

Details

(Whiteboard: [strings])

Attachments

(3 files, 2 obsolete files)

global auto install setting
23.44 KB, image/png
Details
Wording guide
63.25 KB, image/png
Details
Patch v2 - ready for checkin
56.79 KB, patch
Details | Diff | Splinter Review 
Bug 562622 added manual updates. You can set a specific addon to not be updated automatically. However, when a new addon is installed, it defaults to being automatically updated. There should be a way to select the default setting for new addons.
If we want this for 4.0, it needs to be in before beta 5 - since it needs both string changes and API changes.
blocking2.0: --- → ?
Keywords: uiwanted
Blocks: 571527
Version: unspecified → Trunk
(In reply to comment #1)
> If we want this for 4.0, it needs to be in before beta 5 - since it needs both
> string changes and API changes.

Maybe do the API changes here (they have to be done first, don't they, and they aren't blocked by string freeze) and leave the UI to a followup (which might vary per application)?
It's not just default for new add-ons that's needed, but also override for existing.  If you have many add-ons and want to turn off auto install there should be an easier way than:

1. select add-on
2. right click
3. show more information
4. uncheck auto update
5. back

looped for every add-on

One way to accomplish that is to have a global setting (see attachment) with each add-on being able to override it (showing three choices 1.default 2.on 3.off )

    
    

    
  
(In reply to comment #3)
> It's not just default for new add-ons that's needed, but also override for
> existing.  If you have many add-ons and want to turn off auto install there
> should be an easier way than:
...
> One way to accomplish that is to have a global setting (see attachment) with
> each add-on being able to override it (showing three choices 1.default 2.on
> 3.off )

We could, but I think that would complicate it a lot, for relatively little gain - since you're rarely (if ever) going to do a mass change like that.

    
    

    
  
(In reply to comment #2)
> Maybe do the API changes here (they have to be done first, don't they, and they
> aren't blocked by string freeze) and leave the UI to a followup (which might
> vary per application)?

Both parts need done before beta 5 (which is string freeze and API freeze). I might split it once we have a concrete plan for how to do this, but I'd like to keep it in one bug for now - since the UI is going to dictate the API changes.

    
    

    
  
(In reply to comment #5)
> We could, but I think that would complicate it a lot, for relatively little
> gain - since you're rarely (if ever) going to do a mass change like that.

Auto install is analogous to auto check, both are general policy settings.  Would you argue that auto check should only be per add-on? 

It's actually quite likely that you would want to toggle auto install globally rather than per add-on.  You run with it on, decide you want to review updates and now want to turn it off.  Then perhaps you don't want to bother any more with reviewing and decide to turn it on.  It really should be a global setting, just like auto check, and individual add-on override is more of an exception.  Manually looping through dozens of add-ons is an unacceptable burden.

    
    

    
  
(In reply to comment #0)
> Bug 562622 added manual updates. You can set a specific addon to not be updated
> automatically. However, when a new addon is installed, it defaults to being
> automatically updated. There should be a way to select the default setting for
> new addons.

There is such a way in the mockups.  Under the for-lack-of-a-better-name gear menu is the ability to turn automatic updates off.  This control acts as a global setting and applies to newly installed add-ons.

Incidentally, it also overrides individually set exceptions once changed.

    
    

    
  
To clarify:

- Automatic updates checked = all add-ons (except plug-ins) are updated automatically.  New add-ons are also update automatically.  This will be the default in Firefox 4.0

If the user unchecks Automatic updates, all add-ons are then updated manually.
If the user specifies that one or more add-ons update manually, Automatic updates becomes unchecked.

    
    

    
  
Proposed strings:

"Check for updates automatically" (on by default)
"Update add-ons automatically" (on by default)

    
    

    
  
Dave Townsend & I just had a talk about this.  We're propose the following behavior, which is slightly different than what Comment 9 describes.

- The menu item under the gear says "Update add-ons automatically."  It is checked by default.  As long as this item is checked, new add-ons are updated automatically

- If the "Update add-ons automatically" menu item is not checked, new add-ons are not updated automatically

- If the user unchecks Update add-ons automatically, all add-ons become manually updated and new add-ons are manually updated

- If the user checks Update add-ons automatically, all add-ons become automatically update and new add-ons are automatically update

What is slightly different in the above from Comment 9 is that changing whether a particular add-on is updated manually or automatically does NOT alter whether the menu item is unchecked.  The menu item acts as a predictor of FUTURE behavior, NOT and indication of the state of all add-ons.

    
    

    
  
That is not exactly what I had in mind but I think it is probably better anyway. I don't think it is ideal however it looks like the least sucky option of all the sucky options open to us so let's do it. It appears we need a string change here so needs to aim for b5. Do you have time for this Blair?
blocking2.0: ? → beta5+

    
    

    
  
By making the menu item change all individual add-ons, you've just about made it a global setting, as I suggested in Comment 3.  But this makes it so easy to erase per add-on customizations as to make them almost pointless.  The way to get around this is to make it a true global setting with each add-on having the ability to override it.

Each add-on would have three possible settings (instead of two):

1) global default
2) auto
3) manual

with "global default" as the default for all existing and new add-ons.

    
    

    
  
(In reply to comment #12)
> Do you have time for this Blair?

Maybe? If not, we could always just the strings first, and land the rest when its ready.

    
    

    
  
(In reply to comment #13)
> 1) global default
> 2) auto
> 3) manual
> 
> with "global default" as the default for all existing and new add-ons.

This seems to solve a bunch of issues, but at the cost of complexity (although, at least its not hidden complexity). Of course, it probably means the API needs additional changes.

    
    

    
  
(In reply to comment #15)
> (In reply to comment #13)
> > 1) global default
> > 2) auto
> > 3) manual
> > 
> > with "global default" as the default for all existing and new add-ons.
> 
> This seems to solve a bunch of issues, but at the cost of complexity (although,
> at least its not hidden complexity). Of course, it probably means the API needs
> additional changes.

However it loses the ability to quickly make all add-ons update automatically which is something that I think we must have.

    
    

    
  
(In reply to comment #10)
> Proposed strings:
> 
> "Check for updates automatically" (on by default)
> "Update add-ons automatically" (on by default)

"Update" is often an umbrella term for the entire process, so the "check vs. update" distinction is less clear than "check vs. download & install" which is the language already used in options update tab.  Perhaps the second item should be something like:

"Download and install detected updates automatically"

to better disambiguate the two settings.

    
    

    
  
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)
> > > 1) global default
> > > 2) auto
> > > 3) manual
> > > 
> > > with "global default" as the default for all existing and new add-ons.
> > 
> > This seems to solve a bunch of issues, but at the cost of complexity (although,
> > at least its not hidden complexity). Of course, it probably means the API needs
> > additional changes.
> 
> However it loses the ability to quickly make all add-ons update automatically
> which is something that I think we must have.

That could be served by a "reset all add-ons to default/clear overrides" item, that would only be shown if there are overrides (i.e. most of the time it won't be shown and won't be a source of confusion, but those who make overrides will know what it means)

If someone goes through the trouble of making explicit per add-on overrides, their clearing should also be explicit.

    
    

    
  
(In reply to comment #18)
> If someone goes through the trouble of making explicit per add-on overrides,
> their clearing should also be explicit.

Agreed.

    
    

    
  
(In reply to comment #14)
> (In reply to comment #12)
> > Do you have time for this Blair?
> 
> Maybe? If not, we could always just the strings first, and land the rest when
> its ready.
Assignee: nobody → bmcbride

    
    

    
  
Can we shift this to beta6?
blocking2.0: beta5+ → beta6+

    
    

    
  
(In reply to comment #13)
> By making the menu item change all individual add-ons, you've just about made
> it a global setting, as I suggested in Comment 3.  

Exactly.  This is precisely why I'm recommending it over what I described in Comment 9.  With the behavior you described in Comment 3, users can know their global setting and know what the behavior of the next add-on they download will be.

(In reply to comment #13)
> But this makes it so easy to
> erase per add-on customizations as to make them almost pointless.  

It is true that per-addon customizations are erased if the user then makes two global changes (I'll say why two in a second).  

Let's briefly look at the user you're describing here.  This user has individually opened the details pane for one or more add-ons, and those screens has set one or more add-ons to manual updating.  Already this is a user who prefers manual control on *some* but not *all* add-ons, which I'd posit is already rare.  Now, to lose these settings, the user has to change their global setting not once, but twice.  Changing their global setting once would set all add-ons to the setting that was previously the exception manually set, and so their choice was not exactly overwritten.  Perhaps the user wanted to manually update only one add-on, but then decided to manually update all add-ons.  To lose the individual choice that the user set for the one add-on, this user would then have to change back to automatic updates - probably rare for a user who cared enough to make individual add-ons update automatically.  I'd argue that this user and this use case is extremely rare, and at the worst we are asking them to pick the other option on a few add-ons to get their previous state back - not doing anything as serious as data loss, for instance.

I think your idea for a global default, as well as the clear overrides idea in Comment 18, are very successful in showing the actual representation of all the states of add-on installation.  However, given that I expect users to either set all or no add-ons to manual installation, I'd prefer to keep this menu a simple choice between two options rather than introduce a third that relates to so few users.

(In reply to comment #15)
> This seems to solve a bunch of issues, but at the cost of complexity 

Blair provides the tl;dr for the above

    
    

    
  
(In reply to comment #22)

> However, given that I expect users to either
> set all or no add-ons to manual installation, I'd prefer to keep this menu a
> simple choice between two options rather than introduce a third that relates to
> so few users.

If you are referring to the menu item to clear overrides in the gears menu, then as I pointed out, it would not need to be shown unless there are overrides to clear, so for the majority using this as only a global setting the choice remains simple. 

If you are referring to the third choice in the per add-on configuration, then most will never even see it, but for those that do, the choice of (manual, auto, global default) is clearly indicative that this is a per add-on override of the global setting.

Incidentally, I would have expected this to be a global setting first with per add-on overrides, a luxury, time permitting.  But since you have committed to per add-on overrides first, you might as well make them useful.  Without explicit overrides I wouldn't even bother configuring them individually, if I were so inclined.

    
    

    
  
(In reply to comment #22)
> (In reply to comment #15)
> > This seems to solve a bunch of issues, but at the cost of complexity 
> 
> Blair provides the tl;dr for the above

Just to be clear: I was actually in favour of the suggestions in comment 13. I'm not a fan of the added complexity, but I think its better than the alternatives so far.

(In reply to comment #22)
> However, given that I expect users to either set all or no add-ons to manual installation

Not sure I agree with this. But either way, I'm rather worried about making it far easier to disable automatic updates for all addons, than it is to configure only one to be manually updated.
Whiteboard: [strings]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v1 (obsolete)
        — 
          — Splinter Review
      

    


  
Changes Addon.applyBackgroundUpdates to be either enabled, disabled, or default. Fixes tests for that change, and adds some tests. Fixes UI for that change. Adds menuitems under utilities menu to set the default, and reset all addons to use the default.

Also fixes a mistake in the handling of onProperyChanged in head_adons.js.

Not yet done: Tests for menu items.

        Attachment #473537 -
        Flags: review?(dtownsend)
Whiteboard: [strings] → [strings][has patch][needs review mossop]

    
    

    
  
Comment on attachment 473537 [details] [diff] [review]
Patch v1

r- to work out the strings.

>diff --git a/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd b/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd
>--- a/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd
>+++ b/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd
>@@ -37,16 +37,20 @@
> 
> <!-- addon updates -->
> <!ENTITY updates.updateAddonsNow.label        "Update Add-ons Now">
> <!ENTITY updates.updateAddonsNow.accesskey    "U">
> <!ENTITY updates.viewUpdates.label            "View Recent Updates">
> <!ENTITY updates.viewUpdates.accesskey        "V">
> <!ENTITY updates.backgroudUpdateCheck.label   "Check for Updates Automatically">
> <!ENTITY updates.backgroudUpdateCheck.accesskey "C">
>+<!ENTITY updates.installUpdatesAutomatically.label "Install Updates Automatically">
>+<!ENTITY updates.installUpdatesAutomatically.accesskey "A">
>+<!ENTITY updates.resetAutoUpdate.label        "Reset Add-on Updates to Default">
>+<!ENTITY updates.resetAutoUpdate.accesskey    "R">

Don't like these strings but the alternatives are uber-long. Add some tooltips at the very least but also let's get Boriss's take on them.

>diff --git a/toolkit/mozapps/extensions/AddonManager.jsm b/toolkit/mozapps/extensions/AddonManager.jsm

>     this.getAllAddons(function getAddonsCallback(aAddons) {
>       if ("getCachedAddonByID" in scope.AddonRepository) {
>         pendingUpdates++;
>         var ids = [a.id for each (a in aAddons)];
>         scope.AddonRepository.repopulateCache(ids, notifyComplete);
>       }
> 
>       pendingUpdates += aAddons.length;
>+      var autoUpdateDefault = AddonManager.autoUpdateDefault;
>+
>+      function shouldAutoUpdate(aAddon) {
>+        if (!("applyBackgroundUpdates" in aAddon))
>+          return false;

I wonder if this should actually return true.

>+        if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_ENABLE)
>+          return true;
>+        if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_DEFAULT &&
>+            autoUpdateDefault)
>+          return true;

It reads a little nicer to me to change the second case to returning false if AUTOUPDATE_DISABLE and then to just return autoUpdateDefault. Alternatively a switch statement could work. Same later on in extensions.js.

>diff --git a/toolkit/mozapps/extensions/XPIProvider.jsm b/toolkit/mozapps/extensions/XPIProvider.jsm

>     ["userDisabled", "appDisabled", "pendingUninstall",
>      "applyBackgroundUpdates"].forEach(function(aProp) {
>       if (aProp in aProperties) {
>-        stmt.params[aProp] = convertBoolean(aProperties[aProp]);
>+        if (aProp == "applyBackgroundUpdates") {
>+          stmt.params[aProp] = aProperties[aProp];
>+        }
>+        else {
>+          stmt.params[aProp] = convertBoolean(aProperties[aProp]);
>+        }
>         aAddon[aProp] = aProperties[aProp];
>       }
>       else {
>-        stmt.params[aProp] = convertBoolean(aAddon[aProp]);
>+        if (aProp == "applyBackgroundUpdates") {
>+          stmt.params[aProp] = aAddon[aProp];
>+        }
>+        else {
>+          stmt.params[aProp] = convertBoolean(aAddon[aProp]);
>+        }
>       }
>     });

It may be better to just separate out the applyBackgroundUpdates case, but I guess this works. Remove the braces from both if/else statements though.

>diff --git a/toolkit/mozapps/extensions/content/extensions.js b/toolkit/mozapps/extensions/content/extensions.js

>+function shouldAutoUpdate(aAddon, aDefault) {
>+  if (!("applyBackgroundUpdates" in aAddon))
>+    return false;
>+  if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_ENABLE)
>+    return true;
>+  if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_DEFAULT &&
>+      aDefault)
>+    return true;
>+  return false;
>+}

I don't see this ever called with anything other than AddonManager.autoUpdateDefault so why not just pass that in?

        Attachment #473537 -
        Flags: review?(dtownsend) → review-

    
    

    
  
Comment on attachment 473537 [details] [diff] [review]
Patch v1

>diff --git a/toolkit/mozapps/extensions/XPIProvider.jsm b/toolkit/mozapps/extensions/XPIProvider.jsm

>   this.__defineSetter__("applyBackgroundUpdates", function(val) {
>+    if (val != AddonManager.AUTOUPDATE_DEFAULT &&
>+        val != AddonManager.AUTOUPDATE_DISABLE &&
>+        val != AddonManager.AUTOUPDATE_ENABLE) {
>+      val = AddonManager.AUTOUPDATE_DEFAULT;
>+    }

We could say val = val ? AddonManager.AUTOUPDATE_DEFAULT : AddonManager.AUTOUPDATE_DISABLE so if any old code passes a boolean it works out pretty much ok.

    
    

    
  
(In reply to comment #26)
> >+function shouldAutoUpdate(aAddon, aDefault) {
> >+  if (!("applyBackgroundUpdates" in aAddon))
> >+    return false;
> >+  if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_ENABLE)
> >+    return true;
> >+  if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_DEFAULT &&
> >+      aDefault)
> >+    return true;
> >+  return false;
> >+}
> 
> I don't see this ever called with anything other than
> AddonManager.autoUpdateDefault so why not just pass that in?

Because it gets the value from the prefs service each time, which is costly when doing it in a loop. Think I'll change that to an optional argument, and get the best of both worlds (and still not require the hassle of a prefs observer).

    
    

    
  

      
      
      
      

        Attached image
          
        Wording guide
        — 
      

    


  
Attaching Boriss's recommendation for wording.

    
    

    
  
(In reply to comment #26)
> >     this.getAllAddons(function getAddonsCallback(aAddons) {
> >       if ("getCachedAddonByID" in scope.AddonRepository) {
> >         pendingUpdates++;
> >         var ids = [a.id for each (a in aAddons)];
> >         scope.AddonRepository.repopulateCache(ids, notifyComplete);
> >       }
> > 
> >       pendingUpdates += aAddons.length;
> >+      var autoUpdateDefault = AddonManager.autoUpdateDefault;
> >+
> >+      function shouldAutoUpdate(aAddon) {
> >+        if (!("applyBackgroundUpdates" in aAddon))
> >+          return false;
> 
> I wonder if this should actually return true.

Yea, I'm not sure what's the best behaviour there. I originally thought it should default to updating automatically, but now I'm leaning towards the current behaviour. The API has a always assumed that not implemented == don't update automatically. That seems like the safe option - as the provider may internally handle automatic updates itself (kinda like LightweightThemeManager.jsm does).

If you think its worth considering changing, I'd rather do it in a separate bug.


> >+        if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_ENABLE)
> >+          return true;
> >+        if (aAddon.applyBackgroundUpdates == AddonManager.AUTOUPDATE_DEFAULT &&
> >+            autoUpdateDefault)
> >+          return true;
> 
> It reads a little nicer to me to change the second case to returning false if
> AUTOUPDATE_DISABLE and then to just return autoUpdateDefault.

Agreed - that's much nicer.


> >     ["userDisabled", "appDisabled", "pendingUninstall",
> >      "applyBackgroundUpdates"].forEach(function(aProp) {
> >       if (aProp in aProperties) {
> >-        stmt.params[aProp] = convertBoolean(aProperties[aProp]);
> >+        if (aProp == "applyBackgroundUpdates") {
> >+          stmt.params[aProp] = aProperties[aProp];
> >+        }
> >+        else {
> >+          stmt.params[aProp] = convertBoolean(aProperties[aProp]);
> >+        }
> >         aAddon[aProp] = aProperties[aProp];
> >       }
> >       else {
> >-        stmt.params[aProp] = convertBoolean(aAddon[aProp]);
> >+        if (aProp == "applyBackgroundUpdates") {
> >+          stmt.params[aProp] = aAddon[aProp];
> >+        }
> >+        else {
> >+          stmt.params[aProp] = convertBoolean(aAddon[aProp]);
> >+        }
> >       }
> >     });
> 
> It may be better to just separate out the applyBackgroundUpdates case

I did this - it reads a bit nicer.
Status: NEW → ASSIGNED
Keywords: uiwanted
Whiteboard: [strings][has patch][needs review mossop] → [strings][has patch][needs new patch]
Blocks: 595771

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Patch v2 (obsolete)
        — 
          — Splinter Review
      

    


  
Fixes review comments, adds more tests.

Note that this doesn't hide the "Reset all add-ons to update automatically/manually" menuitem when it will have no effect. I want to do that in a followup (bug 595771).

        Attachment #473537 -
        Attachment is obsolete: true

        Attachment #474624 -
        Flags: review?(dtownsend)

    
    

    
  
(In reply to comment #31)
> Created attachment 474624 [details] [diff] [review]
> Patch v2
> 
The phrase "Update Add-ons Automatically" is less clear and more ambiguous than the predecessor.  To me it suggests the entire update process is automated. Since we are talking here about an automatic install of detected updates, after a possibly manual check, "Install updates automatically," which was in V1, is more descriptive.

"Download & install detected updates automatically" is even better, albeit verbose.

        Attachment #474624 -
        Flags: review?(dtownsend) → review+
Whiteboard: [strings][has patch][needs new patch] → [strings][maybe ready to land]

    
    

    
  
(In reply to comment #32)
> (In reply to comment #31)
> > Created attachment 474624 [details] [diff] [review] [details]
> > Patch v2
> > 
> The phrase "Update Add-ons Automatically" is less clear and more ambiguous than
> the predecessor.  To me it suggests the entire update process is automated.
> Since we are talking here about an automatic install of detected updates, after
> a possibly manual check, "Install updates automatically," which was in V1, is
> more descriptive.
> 
> "Download & install detected updates automatically" is even better, albeit
> verbose.

The reason for the phrase "Update Add-ons Automatically" is that for most users most of the time, the update process is indeed automated.  This is a short way to express that automatically (no user action needed), add-ons will be kept current.

Whether or not the user has manually checked for updates, the add-ons are updated automatically if this menu item is checked.  Your recommendation of calling such updates "detect" is redundant - if Firefox knows about the update, it is automatically applied, and that's really the part that's relevant.

al_9x, I thank you for your thoughtful consideration of this problem, but I'm recommending keeping "Update Add-ons Automatically", as it is the most succinct way to describe what happens for the vast majority of users

    
    

    
  


  
Made a tiny change to the test so it opens the addons manager at a specific pane.

        Attachment #474624 -
        Attachment is obsolete: true
Flags: in-testsuite+
Flags: in-litmus-
Keywords: checkin-needed
Whiteboard: [strings][maybe ready to land] → [strings][ready to land]

    
    

    
  
> The reason for the phrase "Update Add-ons Automatically" is that for most
> users most of the time, the update process is indeed automated.

I thought it was just a poor choice of words but it seems you are deliberately misrepresenting what the option does, for alleged simplicity. This makes no sense, as both options will be in the menu (as they should), you can't simplify them away, the best you can do is make their meaning and distinction clear.  

Obscuring, conflating their meaning will not help anyone.  What "Update Add-ons Automatically" does most succinctly is mislead the user that everything is automated, when in fact, update checking may be off.

> Your recommendation of calling such updates "detect"

My recommendation is about naming the two options that control add-on update in a manner that accurately reflects what they do.

1) The first one controls whether Fx checks for updates automatically, hence "check for add-on updates automatically"

2) The second one determines if (automatically or manually) detected updates are then automatically downloaded & installed, hence "download & install detected updates automatically"

    
    

    
  
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/108be9954ccb
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6

    
  
Keywords: checkin-needed
Whiteboard: [strings][ready to land] → [strings]

    
    

    
  
I looked at the latest minefield, and I have to reemphasize that seeing "Check for updates automatically" and "Update add-ons automatically" side by side is going to confuse many not privy to the design.  It really needs to use more precise language for the second one.

The per add-on setting of "default" is not entirely clear.  Here again the language should help the user intuit the underlying design.  What does default mean?  Is it a hard coded value?  Or a global setting?  And what is it?  To answer these questions that will arise in the mind of a user, the pref should say something like: "follow the global setting" and also show the global setting in parens: "Follow the global setting (on|off)"

    
    

    
  
(In reply to comment #37)
> I looked at the latest minefield, and I have to reemphasize that seeing "Check
> for updates automatically" and "Update add-ons automatically" side by side is
> going to confuse many not privy to the design.  It really needs to use more
> precise language for the second one.

We're going to remove the first in bug 595744 but I agree the second is still pretty unclear, going to talk to Boriss to see if we have a more suitable alternative.

    
    

    
  
(In reply to comment #38)
> going to talk to Boriss to see if we have a more suitable
> alternative.

some alternatives:

"(Download &) install detected updates (automatically | without prompting | without user review | without notification)"

"(Present | Show) detected updates for approval" 

"Require updates to be (approved | confirmed) before installing"

"Ask the user whether to install detected updates"

    
    

    
  
> We're going to remove the first in bug 595744

By separating the two settings (and especially if you keep the ambiguous "update automatically" label), you are almost completely obscuring the fact that there are two separate settings controlling different aspects of add-on update behavior.  "update automatically" menu item will appear to the user to be a different interface to the check for updates option.  How is anyone supposed to know that they are two different things?

The only way to make clear that there are two different settings and their purpose is to present them side by side, either in the add-on manager or ideally in the options, and to label them descriptively enough.

    
    

    
  
1) Can one of you please address my previous comment?  Looking at the latest build, it's clear that no one who has not followed this issue would be able to quickly grasp what "Update add-ons automatically" actually means i.e. that it's a different setting that the one in the options and in what way.

2) If autocheck is on but autoinstall is off, shouldn't Fx be notifying in some way of available updates?  AFAICT, currently it doesn't.

    
    

    
  
Since I was asked by Dave via IRC for some feedback, here's my attempt to make the language a bit clearer and have less redundancy:

Check for Updates
Show Recent Updates…
_________________________
Install Add-on From File…
_________________________

✓ Keep Add-ons Updated
Reset All Add-ons to Update Automatically

  (this last option should only be shown if the user has add-ons that don't have the default setting, Dave said there was already a bug on this)

    
    

    
  
"Keep Add-ons Updated" or "Keep Add-ons Updated Automatically" seems like a good choice to me, it shifts it away from sounding like an action.

    
    

    
  
(In reply to comment #43)
> "Keep Add-ons Updated" or "Keep Add-ons Updated Automatically" seems like a
> good choice to me, it shifts it away from sounding like an action.

This is just as misleading, if not more so.  If auto checking is off, "keep add-ons updated automatically" will not keep add-ons updated automatically.  What sense does it make to call it that, when it will not do what it says, will give no clue as to what it actually does and will also be confused with the autocheck setting?

This options controls whether add-on updates detected by either automatic or manual checks are then automatically downloaded and installed.  This is not a new concept for Fx.  Look at the Update tab in the Options.  There are two settings for Fx updates, autocheck and autoinstall, and now it's the same for add-ons.  So why won't you use the same simple and clear language?

https://bugzilla.mozilla.org/attachment.cgi?id=465144

The two add-on update settings (autocheck, autoinstall) belong together, whether in the options or in the add-on manager.

    
    

    
  
(In reply to comment #44)
> This options controls whether add-on updates detected by either automatic or
> manual checks are then automatically downloaded and installed.  This is not a
> new concept for Fx.  Look at the Update tab in the Options.  There are two
> settings for Fx updates, autocheck and autoinstall, and now it's the same for
> add-ons.  So why won't you use the same simple and clear language?
> 
> https://bugzilla.mozilla.org/attachment.cgi?id=465144
> 
> The two add-on update settings (autocheck, autoinstall) belong together,
> whether in the options or in the add-on manager.

That isn't really a good option either since, unlike app update, we allow individual exceptions for add-ons.

I've talked with a few of the product drivers about this today and we're basically of the opinion that this UI is not great. We have one saving grace. The first interaction the user has with this menu will show the menuitem as checked. Obviously that doesn't help them if they uncheck it then look days later but it is something. Pretty much any change we make to this string could be mis-construed one way or another so perhaps we are barking up the wrong tree completely but we are at string/feature freeze so it is too late to do anything other than wording changes (technically we were meant to have frozen last night).

Fixing this string is not going to block the string freeze and since we can't seem to reach any agreement over what change we would make we're not going to waste any more time focusing on it and we'll just have to live with what we have and see what kind of feedback we get through our user channels.

    
    

    
  
This really is simpler than you make it out to be. You know what the autoinstall setting does, so you either name it truthfully and accurately or you mislead and lie.

It does not "Keep Add-ons Updated," not if autocheck is off.  To call it that is a lie.  Don't do it.

The phrase that most accurately describes the function of the autoinstall setting is:

"When updates are found, download and install them automatically"

for maximum clarity the two settings should be presented side by side, this leaves no confusion or ambiguity about their purpose:

"Periodically check for updates"
"When updates are found, download and install them automatically"

__________________________________________________________________

The following was never addressed:

If autocheck is on but autoinstall is off, shouldn't Fx be notifying in some
way of available updates?  AFAICT, currently it doesn't.  Only when you open the add-on manager do you see the auto-detected updates.

    
    

    
  
(In reply to comment #46)
> This really is simpler than you make it out to be. You know what the
> autoinstall setting does, so you either name it truthfully and accurately or
> you mislead and lie.
> 
> It does not "Keep Add-ons Updated," not if autocheck is off.  To call it that
> is a lie.  Don't do it.

As I said, we aren't going to make any changes now.

> The phrase that most accurately describes the function of the autoinstall
> setting is:
> 
> "When updates are found, download and install them automatically"

This is only true for add-ons that do not have explicit options set and give the UI it has to appear in it is too long to be readable IMO.

> The following was never addressed:
> 
> If autocheck is on but autoinstall is off, shouldn't Fx be notifying in some
> way of available updates?  AFAICT, currently it doesn't.  Only when you open
> the add-on manager do you see the auto-detected updates.

Please file a bug on this.

    
    

    
  
(In reply to comment #47)
> (In reply to comment #46)
> > This really is simpler than you make it out to be. You know what the
> > autoinstall setting does, so you either name it truthfully and accurately or
> > you mislead and lie.
> > 
> > It does not "Keep Add-ons Updated," not if autocheck is off.  To call it that
> > is a lie.  Don't do it.
> 
> As I said, we aren't going to make any changes now.
> 

The time to get this right is now, not after 4.0 is released.  Splitting them was a bad idea and the current label is misleading.

> > The phrase that most accurately describes the function of the autoinstall
> > setting is:
> > 
> > "When updates are found, download and install them automatically"
> 
> This is only true for add-ons that do not have explicit options set and give
> the UI it has to appear in it is too long to be readable IMO.
> 

Yes, add-ons can override the global setting, but it's meaning is still best encapsulated by the phrase I gave, certainly not by "keep add-ons updated"

> > The following was never addressed:
> > 
> > If autocheck is on but autoinstall is off, shouldn't Fx be notifying in some
> > way of available updates?  AFAICT, currently it doesn't.  Only when you open
> > the add-on manager do you see the auto-detected updates.
> 
> Please file a bug on this.

Bug 597567

    
    

    
  
Verified fixed with builds on all platforms like Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101011 Firefox/4.0b8pre
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: