Closed Bug 553503 Opened 10 years ago Closed 9 years ago

Add UI for toggling automatic update checking/installing


(Toolkit :: Add-ons Manager, defect, P2)




Tracking Status
blocking2.0 --- final+


(Reporter: Unfocused, Assigned: Unfocused)



(Whiteboard: [rewrite][fixed by bug 562622])


(1 file, 1 obsolete file)

Add UI for toggling automatic update checking/installing.
Priority: -- → P2
This bug is intended for the preference dialog?
It's still currently still being debated where to put it.
Keywords: uiwanted
(I'm copying and pasting comment from bug 553502 regarding placement of UI for toggling automatic update checking and installing - attachment should make it clear)

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.
Updating mockup - per discussion, a menu with options to manually check for updates and update
Attachment #439345 - Attachment is obsolete: true
So toggling the pref can be fixed by the work on bug 562622 now?
(In reply to comment #5)
> So toggling the pref can be fixed by the work on bug 562622 now?

This bug is part of that, yes. And those mockups provide a place to put this UI.
Blocks: 562622
blocking2.0: --- → beta1+
blocking2.0: beta1+ → beta2+
Assignee: nobody → bmcbride
blocking2.0: beta2+ → final+
Version: unspecified → Trunk
Duplicate of this bug: 579321
Duplicate of this bug: 584017
Fixed with the landing of bug 562622.

Normally I'd say this doesn't need any litmus tests, but half of the automated test had to be disabled (temporarily, I hope). So testing actual UI interactions (clicking the "Check for Updates Automatically" menu item) isn't completely covered right now. See bug 583668.
Closed: 9 years ago
Flags: in-testsuite+
Flags: in-litmus?
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100826 Minefield/4.0b5pre

All remaining issues I have filed dependent on bug 562622.
Target Milestone: --- → mozilla2.0b3
No longer depends on: 591027
Whiteboard: [rewrite] → [rewrite][fixed by bug 562622]
Flags: in-litmus? → in-litmus?(vlad.maniac)
You need to log in before you can comment on or make changes to this bug.