It would be nice to be able to leverage our multi-process architecture and at least start using the new binaries for any new tabs that are created. But, that's a different can of worms, I guess. On Sun, Mar 29, 2009 at 14:31, 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 -~----------~----~----~----~------~----~------~--~---
