340156 - modify final page of update wizard to include name of update, link to details, restart button that saves state

Status: RESOLVED DUPLICATE of bug 346795

(Toolkit :: Application Update, defect)

Description

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

By default, incremental updates that don't break extensions are installed silently. The first time a user is notified that the update has been found and is being downloaded is when it's time to restart their browser to apply said update.

As pointed out in bug 340108, this can be disconcerting since there's no additional information about the update that's been installed. The final screen of the update should be modified to read:

   Update Downloaded

   The update to &prodName; &verNumber; has been successfully downloaded
   and verified.

   You can either apply the update now (&prodName; will restart, but we'll
   remember where you were and re-open your windows and tabs) or click "Later"
   and the update will be applied the next time you start &prodName;.


                                [ Apply Update Now ] [ Apply Update Later ]

Comment 1

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

(In reply to comment #0)
Durr. Let's try this again.

  Update Downloaded
 
    The update to &prodName; &verNumber; has been successfully downloaded
    and verified. You can find out more about this update _here_.
 
    You can either apply the update now (&prodName; will restart, but we'll
    remember where you were and re-open your windows and tabs) or click "Later"
    and the update will be applied the next time you start &prodName;.
 
 
                                 [ Apply Update Now ] [ Apply Update Later ]
 

not sure about the text or how the link is done in there ... feels wrong to me at the moment, but better to get something down on paper; please feel free to refine.

Comment 2

[Darin Fisher]

The restart w/ restored state thing raises one question in my mind:  if we cannot restore state 100%, then maybe we shouldn't promise to restore state.  Afterall, as a user I would learn quickly to distrust firefox if it were ever unable to restore state 100% when it told me that it was going to do so.  Just my 2c!

Comment 3

[Jeff Walden [:Waldo]]

Attachment: Current background update UI

This is what the current background update UI looks like -- that certainly looks like "additional information about the update" to me.  Everything in your proposed change is there in some form (except for the session restore info, which can be trivially added).  Is the bug here to change the UI from what it is to what's proposed, or can we just do some slight tweaks to what's there already to reflect sessionstore?

Comment 4

[Jeff Walden [:Waldo]]

Oh, the session isn't restored yet.  Okay, that looks like it'll be fun, then, if it's even possible given the current state of sessionstore's non-existent API.

Comment 5

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

Dietrich can likely give you a bug number to hang a dependency on. He's good like that.

Comment 6

[Mike Connor [:mconnor]]

calling restart from nsIAppStartup should automatically restore the session now.

Comment 7

[Jeff Walden [:Waldo]]

Some things I'm currently batting around:

I hadn't realized it when I wrote comment 3, but there is currently no update code in browser/; everything displayed is in toolkit/ or is sent with the downloaded update data itself.  Displaying app-specific strings (since state-saving behavior should not be the default assumption for non-Firefox apps) will mean the changes will have to start touching browser/, which may or may not be desirable.  Such changes would, however, be trivial with a small overlay.

(In reply to comment #2)
> The restart w/ restored state thing raises one question in my mind:  if we
> cannot restore state 100%, then maybe we shouldn't promise to restore state. 

We can't save download state (see bug 230870), and the restart doesn't retry downloads which are cancelled by the shutdown.  (Hacking together something here would probably not be difficult, if we really wanted to do something close to the right thing.)  This in particular makes me think we should not pretend to save state, since downloading is a core part of the browser.  Additionally, extensions which have state to save must be written to hook into sessionstore, and for a while until 2.0 gains a user base and extension authors catch up, most will not be saving such state.  (Consider Chatzilla with scrollback without logging enabled.)  The combination of the two (perhaps even just the first, actually) makes me think we should not promise to restore browser state.

Thoughts on this, particularly on the second part?

Comment 8

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

Due to the amount of string changes and the fact that the existing UI is passable, I'm taking this one off the blockers list and retargetting at Firefox 3.

Comment 9

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

*** This bug has been marked as a duplicate of 346795 ***