Closed Bug 511529 Opened 15 years ago Closed 14 years ago

make add-on update work more like software update

Categories

(Toolkit :: Add-ons Manager, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: beltzner, Assigned: Unfocused)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ts][perception])

When add-ons get updated, the user's normal startup is interrupted and users are asked if Firefox should download and install the update, which requires a browser restart. This design was intended to prevent the annoying case where shortly after browser startup, an add-on update would be detected and a dialog would pop up asking users to install and restart. However, the effect is that it delays startup either a little bit (while the check takes place) or quite a lot (as the update is downloaded and installed).

Updates to add-ons, like updates to the application, should happen by default and take place in the background with minimal user interaction.

This will probably need several bugs:

 - we should check for add-on updates after the browser has started
 - if updates exist, we should download them in the background as the user browses
 - if the browser is shut down within 24 hours, we shouldn't even notify users
 - if the browser is left open for more than 24 hours, we should notify the user that updates are available (tying in to existing notification mechanisms for application update)
 - updates should be installed on shutdown/restart
 - after updates finish, users should be notified (infobar?) that add-on updates have taken place and shown how they can turn off automatic updates
 - if automatic updates are off, only update through manual checks and when the browser compatibility version changes
This is a big Ts win, because it means that we would remove one of the major reasons why we initialize NSS at startup.
Whiteboard: [ts]
(In reply to comment #1)
> This is a big Ts win, because it means that we would remove one of the major
> reasons why we initialize NSS at startup.

The extension manager does not, in general, touch the network during startup so I don't believe that this is the case.
Blocks: 366777, 449216, 478284
Severity: normal → enhancement
Depends on: 321789, 464461
Whiteboard: [ts]
Version: 1.9.0 Branch → Trunk
My experience is otherwise -- I'm often prompted for extension updates, even when I have not updated the browser.  The other place is the URL Classifier though, which does a ping every time it starts up.
(In reply to comment #3)
> My experience is otherwise -- I'm often prompted for extension updates, even
> when I have not updated the browser.

Being prompted to install extension updates does not mean that we detected extension updates there and then. The updates would have been detected the last time Firefox was running.

Left to its own devices the extension manager won't do a background update check until Firefox has been running for at least 10 minutes.
Well, if that's true, we should find out why *else* we initialize NSS at startup and move on to killing that.

However, despite the measurable Ts wins that Vlad is referring to with NSS startup, I was actually referring to the perceived startup time to the user. When I click my Firefox icon, I want to use the web, not be asked questions about add-on updates. Further, while it's true that we detect the existence of the update, we don't have it downloaded until the user agrees to do so; I think that's optimizing the wrong way.
No longer blocks: 366777, 449216, 478284
Severity: enhancement → normal
No longer depends on: 321789, 464461
Whiteboard: [ts]
Version: Trunk → 1.9.0 Branch
Blocks: 366777, 449216, 478284
Severity: normal → enhancement
Depends on: 321789, 464461
Version: 1.9.0 Branch → Trunk
Whiteboard: [ts] → [ts][perception]
For me as a plain user this is an important issue. I'm a traveling laptop user and reasonably often I don't have internet connectivity or my proxy is not yet configured for the location I am. In these cases I find the mandatory update check during startup a pain.

I like the Windows Update kind way of doing things: Donwload updates in the background and eventually ask me if I want to install them. I might even like a configurable option 'install without asking'.
I use Firefox because I dislike Internet Exploder, and Netscrap so fell in love with Firefox.
But I am starting to agree with my wife THAT START UP TAKES F O R E V E R !!!!

Load a little Fox that shows startup is working, the BLANK SCREEN dosen't cut it.  After I finish my coffee, (waiting) I again click on the icon to load and then again (waiting) and after I walk away and come back from walking the dog I have three windows of Firefox finally open (close two). 
MicroSoft finally listened and is attempting to fix start up with the new Ver 7 OS and loads only the necessary to get started (not every program on the drive or in the start up file)

I don't want to wait for Firefox to load every feature in the universe and check for updates and what ever else it does. I don't want to Know. Just load something on the page and show me it is in fact loading.  I know you can do it!
blocking2.0: --- → ?
OS: Mac OS X → All
Hardware: x86 → All
Guys I totally agree. Add-on updates in firefox are probably the most annoying and obtrusive feature. 

Instead they should be SILENT, unobtrusive and presented to the users with a small notification bar on top (just like when a site is trying to install an addon etc, or at a different location just to make sure users know the difference). Finally, they should of course be installed at the END of the session.
Blocks: 447581
blocking2.0: ? → beta1+
THer parts of this necessary for beta have been fixed with the new add-ons manager, still need to wire up better notifications though.
blocking2.0: beta1+ → final+
Assigning this to you Blair, however I don't think there is anything to do above the existing update changes you have.
Assignee: nobody → bmcbride
A lot of this was fixed in bug 562622. I think the only think that's missing is additional notifications.
(In reply to comment #13)
> A lot of this was fixed in bug 562622. I think the only think that's missing is
> additional notifications.

This is still marked blocking, but I don't really understand what the remaining work looks like or, being past feature/string freeze, whether it is still containable. Little help?
I think we're done here, faaborg said he didn't want the additional notifications, anything else should be filed as individual issues.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
(In reply to comment #15)
> I think we're done here, faaborg said he didn't want the additional
> notifications, anything else should be filed as individual issues.

Done. So marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
Flags: in-testsuite-
Flags: in-litmus-
You need to log in before you can comment on or make changes to this bug.