Consider making session_manager restart Chrome when it crashes while locked |
||
Issue descriptionFrom an email conversation: "We may want to think about removing the log-out-on-lock-screen-crash behavior now. It'd probably be possible to add a flag to Chrome that session_manager can pass when restarting it to tell it to display the lock screen initially." "I think the current behavior is mostly carried over from the pre-Ash days when we ran a separate process to display the lock screen -- if the lock program crashed, we wanted to make sure that Chrome wasn't exposed. Chrome already knows how to go directly into a user session at startup (e.g. for a flag change or when the browser crashes), so it seems reasonable to consider supporting going back to the login screen." So if we did this, we'd probably add a --lock-screen or similar flag to Chrome that session_manager could pass if it wants Chrome to come up with the screen locked. session_manager already passes similar flags to Chrome in other situations (see --login-manager, --login-user, and --login-profile in BrowserJob::StartSession). Jacob, assigning to you to get your thoughts about how feasible this would be to do on the Chrome side. I can help out with the session_manager side of it if we do it.
,
Mar 12 2018
Timing could be a problem when there are multiple user sessions. It takes a D-Bus round trip to get those user hashes from session_manager and restore them. The lock screen might be showing the primary user instead of the last active user. We might need extra wiring to update users on the lock screen. Another concern is crash loop. We should only attempt to start chrome in locked state in limited number of times.
,
Mar 12 2018
Thanks for the details. Not doing this if it's tricky or risky also seems reasonable to me. :-)
,
Aug 3
This bug has an owner, thus, it's been triaged. Changing status to "assigned". |
||
►
Sign in to add a comment |
||
Comment 1 by jdufault@chromium.org
, Mar 10 2018