This isn't power related, removing the component.

I think I'm fine with session_manager's Chrome-exit timeout being increased.

The dedicated-restart-button feature request seems unrelated to this. Please file a separate bug for it. (What's the use case for restarting when there's no update? Is it just a development thing, or are there reasons non-dev users would want it?)

Thanks.  Filed issue 840001.

Not sure what component this should be under. None of the existing ones seem to fit.

I'm OK with increasing the timeout if we need to, but I'd rather investigate what are the running tasks that are timing out on shutdown and can we get them to finish in a reasonable time.

Alternatively, can we make it so that if the browser is killed in this way that we DON'T lose session state?

I think it's OS>Systems.

First, I think, we should find out how much of a problem this is, and if any metrics we're collecting are correct.

I thought we had looked at this more recently, but the only bug I found is  issue 191054  from 2010.
 

Should be possible to get a view of this from crash/. I'll dig into it.

Is there anything more I can give?  This seems to hit ~100% of the time for me.

#9: Jeff, are you the original reporter? If so, I have some followup questions:

a) How are you updating? After you see that an update is pending, are you applying it by signing out, or by clicking "Restart to update" in the system menu, or by shutting the system down (and if so, how are you doing this?), or through some other means?

b) Do your tabs always get restored if you just log out and back in without applying an update?

c) Does the problem ever happen without you seeing the yellow "Chrome has crashed" bar?

d) Conversely, do you ever not see the yellow bar after applying an update, or do you always get it?

I'm also removing the proposal to increase the exit timeout until we're sure that that's relevant here. I think that at least in some cases session_manager only knows that Chrome wants to exit because the browser process exits with status code 0 (i.e. signout is Chrome-initiated), in which case the timeout wouldn't be relevant. I think it might only come into play when the browser process exits immediately but other Chrome processes stick around longer.

Some feedback reports that I haven't looked at yet:

http://feedback/#/Report/85395490265
http://feedback/#/Report/85444905972

http://feedback/product/208/neutron?lView=rd&lReport=85444905972 pointed me at http://crash/browse?q=reportid=%27731fad61325bf8c9%27. I think that this is issue 850626.