I'm supportive of some UI to let the user know that there is a update pending. This should be non-model and minimally distracting. We've talked about a notification area on the NTP. It would also serve as a place that we could tell people about cool new features. We'll throw this on the queue for the UI team to mock up (if we don't have mocks already).
On Sun, Mar 29, 2009 at 3:49 PM, John Grabowski <[email protected]> wrote: > This is a very delicate line to walk. We want to silently update... yet > not actually be silent. We want updates to take effect immediately... yet > not require an app restart. You have provided some good ideas but, in > practice, it can be difficult to close on a compromise that doesn't make > some subset of players very upset, or expose a new class of complexity. > > Chrom(ium) packaging and resource finding is different on each platform, > which has implications for an update strategy. For the Mac, thomasvl is > currently reworking the app structure, so it is probably best to wait for > his work to complete before we make a proposal. > > jrg > > On Sun, Mar 29, 2009 at 2:31 PM, Jim Roskind <[email protected]> wrote: > >> Perhaps we need to think about how to encourage such a restart, without >> being the traditional pop-up pain-in-the-er-um-rear. >> Can we find real-estate that won't tend to detract from the ui to alert >> the user that an update is pending? Perhaps atop a new-tab page? Perhaps >> an extra entry ot the top-level "wrench" menu? ...in a different color >> near "About Chrome"?? On windows, should we be alerting the user via the >> little "updates are pending" dialog that Windows and others are using?? >> >> Can we make the update especially painless for users, >> by temporarily opting them into to restore the existing tab settings, even >> if they don't usually do so?? >> >> Can we do other things to make it easy, and obvious to encourage a user to >> allow an upgrade? I don't think it is possible... but can we detect when it >> would be a "good time" to upgrade, and just "help them along?" I suspect >> that too much state would be lost (sign in, cookies, SSL session keys, etc. >> etc.). Maybe we can "detect* that they are in a "very reproducible state" >> and that "they are quiescent" and then do the update (perchance a large >> percentage of users live in such states)?? Can we do some fancy >> optimization to do most of the startup of the new version before we shut >> down the old version, so the transition is super-fast?? >> >> It is clear to me that our wonderful work to "crash less" is working... >> and greatly extending the time-till-update after the user has the downloaded >> update on disk. IMO, delaying an upgrade is probably a Bad Thing (TM) for >> the user (which is why we push out better versions)... but interrupting a >> user's action is a very Bad Thing. Can we improve the compromise, and help >> the user? >> >> Jim >> >> On Sun, Mar 29, 2009 at 1:25 PM, Erik Kay <[email protected]> wrote: >> >>> >>> On Sun, Mar 29, 2009 at 1:02 PM, Thomas Van Lenten >>> <[email protected]> wrote: >>> > Most mac apps solve this by having the app exit as part of the upgrade >>> > process, this way a new copy is launched w/ the new resources. >>> >>> yes, but this is the problem with silent autoupdate. We don't want to >>> force the user to stop what they're doing when an update starts. >>> >>> Erik >>> >>> >>> > On Sun, Mar 29, 2009 at 4:40 AM, John Grabowski <[email protected]> >>> wrote: >>> >>> >>> >>> How will in-place updating work on the Mac and Linux? >>> >> >>> >> To be frank, we haven't solved this problem on Mac. >>> >> Right now we're doing an rsync to klobber on update, which is fine for >>> >> pre-dogfood. E.g. our "normal" Mac crash rate far exceeds any >>> possible >>> >> crashes caused by version mismatching in the 3 auto-updates we have >>> sent out >>> >> internally. >>> >> Although we could load all resources on startup, that ignores one >>> critical >>> >> piece. Since renderers are separate processes and are launched >>> on-demand, >>> >> we would still have the problem of "old browser" talking to "new >>> renderer". >>> > >>> > All platforms would have this problem if they don't force the apps to >>> bounce >>> > as part of the upgrade process, no? >>> > TVL >>> > >>> >> >>> >> I suspect we'll need to have either a versioned scheme line Windows, >>> or a >>> >> "complete upgrade" step on initial launch. >>> >> jrg >>> >> >>> >> >>> >> >>> >> >>> >> >> >>> > >>> > >>> >>> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
