366777 - [meta] move add-ons update notification to after app startup

Status: VERIFIED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Robert Strong (they/them - no direct email)]

Bug 347585 will add an application notification widget that we should use for extension update and application update notification. This bug will track all of the bugs caused by having extension update notification take place during startup that will be fixed by using an application notification widget as well as any work that needs to be done to the extension manager for it to use the application notification widget.

Comment 1

[Matt Wills]

My two cents' worth: the issue with updating extensions is for me not so much in session restore as it is in cold launch.

Clicking a link in another app (such as Eudora) and launching FF, the update makes FF forget where it was going. I always end up at my Google page if update has interrupted startup, upon which I have to go back to Eudora and click the link again.

(FF 2.0.0.3, OSX 10.4.9)

Matt

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to bug 297903 comment #17)
> There are a ton of problems with notification on startup. See meta bug 366777.

Those are all problems with the current implementation, sure, and they should all be fixed, but none of those problems seem to be with the current user experience - installing updates to extensions on startup makes an incredible amount of sense as long as we can do it quickly and efficiently. I'd rather we focus on fixing those bugs than retreat from the experience we're providing now by going back to one that's more like the "Christmas Tree" offered in Firefox 1.0; all evidence showed that system was undiscoverable and resulted in fewer add-on updates being applied.

So, for example, I'd like to see a solution like the one proposed in bug 297903 by Mossop which would effectively close bug 361129 and bug 348419.

(In reply to bug 297903 comment #18)
> not to mention that app startup is a fragile place to be doing this as has
> been seen previously with the add-ons compatibility wizard.

By adding a secondary layer for notification (which was, by my understanding, the point of bug 347585) we allow a fall-back position for when we detect breaks of the nature (I think) you're describing here. If we can't get a read on the update, or if the update is taking too long, we can just start the rest of the app and then use the notification widget to signal completion.

My opinion is that this bug should be WONTFIXed, but its dependencies should be fixed and bug 347585 should be morphed so that it's not replacing, but augmenting the existing add-on update UI.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to comment #2)
> (In reply to bug 297903 comment #17)
> > There are a ton of problems with notification on startup. See meta bug 366777.
> 
> Those are all problems with the current implementation, sure, and they should
> all be fixed, but none of those problems seem to be with the current user
> experience - installing updates to extensions on startup makes an incredible
> amount of sense as long as we can do it quickly and efficiently. I'd rather we
> focus on fixing those bugs than retreat from the experience we're providing now
> by going back to one that's more like the "Christmas Tree" offered in Firefox
> 1.0; all evidence showed that system was undiscoverable and resulted in fewer
> add-on updates being applied.
Though I agree with it being a decent user experience to some degree my main concern is having to play wack a mole with the known and unknown bugs caused by doing this at startup.

btw: how about displaying software update notifications at startup too then so we can avoid having the dialog get in the way of browsing?

> So, for example, I'd like to see a solution like the one proposed in bug 297903
> by Mossop which would effectively close bug 361129 and bug 348419.
No it does not. That bug will display info about the update in a chrome browser window and does not prevent the overwriting of session info when opening the add-ons homepage, etc. which also blows away session restore as it relates to the two bugs you cited.

> (In reply to bug 297903 comment #18)
> > not to mention that app startup is a fragile place to be doing this as has
> > been seen previously with the add-ons compatibility wizard.
> 
> By adding a secondary layer for notification (which was, by my understanding,
> the point of bug 347585) we allow a fall-back position for when we detect
> breaks of the nature (I think) you're describing here. If we can't get a read
> on the update, or if the update is taking too long, we can just start the rest
> of the app and then use the notification widget to signal completion.
Not at all... I am referring to that our startup code tends to be fragile in that it isn't a safe place to display ui since not everything has been initialized. For example, we've had crashes specific to Mac OS X that weren't noticed for at least a week (maybe a month) when displaying ui at this stage, iirc Linux wouldn't theme the clear private data ui properly, and random other bugs with the add-ons compatibility wizard. This is why other components don't try to display ui at this stage in startup and I would really prefer not to with the EM as well.

> My opinion is that this bug should be WONTFIXed, but its dependencies should be
> fixed and bug 347585 should be morphed so that it's not replacing, but
> augmenting the existing add-on update UI.
Whatever the case this bug should not be WONTFIXed though I am open to morphing it to a meta bug for resolving add-on updates on startup and fixing and / or living with any unfixed bugs for Firefox 3.0 caused by doing this on startup.

Comment 4

[AndrewM]

Should the target milestone for this bug be updated, since alpha 2 was months ago?

Comment 7

[Dave Townsend [:mossop]]

We don't use this update notification anymore