452.21 KB, image/png
There's no UI exposed for manually starting an all-addons update check. Should probably add one.
This may be a candidate for fligtar's Discovery pane. It would be hard to justify putting this in particular in Prefs, removed from the item it's effecting.
Think you're thinking of bug 553503 for toggling the pref. Here, I'm talking about a button to start checking for updates for all addons, regardless of whether the automatic checkes are enabled or not. The same as the "Find updates" button in the old extension manager.
Version: unspecified → Trunk
(In reply to comment #2) > Think you're thinking of bug 553503 for toggling the pref. > > Here, I'm talking about a button to start checking for updates for all addons, Yes, I'm referring to the same. If we're by default updating all add-ons automatically, it's less of a "check" for add-ons and more of an "update all add-ons right now." The use case for this is likely if a user knows of a particular update they want for a particular add-on or two, but they haven't yet received the automatic update and want to hurry the process. If the user has turned automatic updates off, then I'm afraid they probably need a separate workflow to both check for all updates and then to choose they ones they want to install. There are mockups here ( https://wiki.mozilla.org/Firefox/Projects/Extension_Manager_Redesign/design#Updating_Add-ons_Automatically_and_Manually ) for a user disabling automatic updates on a particular add-on and checking for updates on that particular add-on, but there needs to be a global option. Let's talk about this at our meeting (in 5 minutes), and I'll make some mocks.
(In reply to comment #3) > particular update they want for a particular add-on or two, but they haven't > yet received the automatic update and want to hurry the process. In which intervals we are checking for new versions of addons?
Assignee: nobody → bmcbride
I'm attaching a mockup of my recommendation on how to handle checking for updates manually and installing updates manually. First, I no longer think we should support the case of letting the user let all updates be automatic except for a few add-ons. This third "middle" case leads to strange edge cases in installation, and I don't feel it's worth creating a confusing partial case for what is likely a small amount of users. If we limit our scope to two kinds of users (those that want automatic updates (default) and those that don't (selected via Preferences)) the installation process become much clearer. In the automatic case, I recommend adding a button to each category page to "Update Add-ons." This both checks for updates and installs them, all from within the category page, and prompts the user to restart if necessary. If the user has selected that they want manual updates, they get an "Updates" pane much like in the current add-ons manager. This pane only shows updates that are available to install, and lets the user install them from within the Updates pane. Instead of an "Update Add-ons" button in each category, the user gets a "Check for Updates" button which that links them to the Updates pane. The above cases don't cover a log of previously installed updates. I've talked with Limi, who's working on the new Download Manager, and his plan is to make the Download Manager a resource for *all* files downloaded - even Firefox updates and Add-on updates. These are not displayed by default in the Download Manager, but can be shown if selected. I'm recommending that we use this as the add-on manager log, so if the user needs a record of what's been updated it's with all the other items that have been downloaded.
Needs some (visual) polish, but the button and status is there now: http://hg.mozilla.org/projects/addonsmgr/rev/496c82e83c58 Not done: There's no way to cancel the checking/downloading yet.
Whiteboard: [rewrite] → [rewrite][fixed-in-addonsmgr]
(In reply to comment #4) > In which intervals we are checking for new versions of addons? The pref for this is stored in extensions.update.interval, and defaults to every 24 hours.
Landed on trunk as a part of bug 554007
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [rewrite][fixed-in-addonsmgr] → [rewrite]
Target Milestone: --- → mozilla1.9.3a5
Verified fixed with builds on all platforms like Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100511 Minefield/3.7a5pre GTB7.1 ID:20100511040317 Litmus tests will be added after the work on bug 562622 has been landed. Removing left-over uiwanted keyword.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.