New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 673365 link

Starred by 5 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

chrome:restart stopped working on Windows

Project Member Reported by elawrence@chromium.org, Dec 12 2016

Issue description

Chrome Version: 57.2949
OS: Windows

What steps will reproduce the problem?
(1) Visit chrome://restart

What is the expected result? All browser windows close and reopen to same tabs

What happens instead? All browser windows close. User must manually restart.

I first noticed this regression last week in Canary. I click the green upgrade arrow and choose "Relaunch" on the "Chrome hasn't restarted in a while" prompt. All of my browser tabs and windows close, but never reopen. Clicking the Chrome icon in the Quick Launch area restarts the new Canary and reopens all of my tabs.

chrome://restart exhibits the same behavior; all browser instances close but do not reopen. Process Explorer does not appear to show any attempt to spawn a new Chrome process. Windows v57.0.2949 repros; Mac does not.

 
Labels: Needs-Bisect
Chromium and "bisect-builds.py -a win -g 433059 -b 437811 -- --no-first-run --user-data-dir=/temp" do not appear to reproduce the issue, even on the latest build.

In the failing case, the "Local State" shows "was":{"restarted":true}} even when the browser failed to restart.
This may be related to the DesktopFastShutdown experiment.
Cc: gab@chromium.org
Components: Internals>PlatformIntegration
Owner: manzagop@chromium.org
Status: Started (was: Untriaged)
It sounds likely the DesktopFastShutdown is to blame: it's on for 10% of canary and switches all exits to use the fast exit path.
I checked the code and this seems right. I think we have enough data to make an assessment, so I'll turn down the experiment.

Comment 7 by ajha@chromium.org, Dec 13 2016

Labels: -Needs-Bisect
I am able to reproduce the issue on the latest Chrome canary(57.0.2949.0) but same worked fine on the chrome-unsigned build of(57.0.2949.0).

Checked the Finch Hashes and this indeed looks to be related to 'DesktopFastShutdown- Default'. The experiment doesn't show up on unsigned build of the same chrome version where issue is not reproducible.

Removing the Needs-bisect label as root cause is already identified and unable to get the good and bad build as it is experiment related.
Confirming the experiment was turned down yesterday. The behavior should no longer be reproducible after a restart (late yesterday or today).
Status: Fixed (was: Started)

Sign in to add a comment