Multi-profile session restore broken with --no-startup-window |
||||||
Issue descriptionI've been noticing for some time a few things that I found odd: - Chrome opens up visible browser windows when I sign into my Win box. - Chrome often doesn't open up windows for *one* of my profiles when launching this way. It finally irritated me enough that I debugged into StartupBrowserCreator::ProcessLastOpenedProfiles to see just what's going on. Here's the scoop: the handling of kNoStartupWindow is in StartupBrowserCreatorImpl::DetermineURLsAndLaunch. It basically says "if we're launching a new browser process and --no-startup-window is specified, don't open any urls at all." That seems okay, except that this is within StartupBrowserCreatorImpl::Launch, which is called once per profile. After the call to StartupBrowserCreator::LaunchBrowser for the first profile, is_process_startup is flipped to IS_NOT_PROCESS_STARTUP. All following profiles, therefore, have their browser windows opened. It looks to me like is_process_startup conflates two concepts: 1) is this the first launch of a browser process, and 2) is some particular |profile| the first of N that may be opened/restored for this particular launch. I imagine this is a problem on all desktop platforms. I think the correct behavior is for no windows to open when --no-startup-window is specified. If I (the user of this box) were to later click on Chrome's icon in the taskbar, windows for all N profiles should open as if this was a fresh launch with full session restore.
,
Jun 11 2018
It's my understanding that background mode was created for extensions/apps that have the bg priv and Chrome's "Continue running background apps when Google Chrome is closed" setting is enabled (the default, I think), hence my adding the Extensions component to this bug.
,
Jun 11 2018
Yeah, this is more of an issue for the folks maintaining the browser startup code - agreed that this is triggered primarily by extension background mode, but it's not in the extension codebase per se. 100% agreed that the correct behavior would be to not open any windows on startup if --no-startup-window is passed. I'm guessing some refactor over the last 5 years broke this.
,
Jun 12 2018
tmartino: do you know of a good candidate to take ownership of this?
,
Jun 12 2018
,
Jul 13
--Chrome Identity automated triaging-- This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 2
,
Sep 3
--Chrome Identity automated triaging-- This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by rdevlin....@chromium.org
, Jun 8 2018Components: -Platform>Extensions