Chrome shows prompt dialog for "Restore Pages" after every debugging session.

[akutruff]

Describe the bug

After a normal debugging session, launching another debugging session always shows "Restore Pages? Chrome did not shutdown correctly."

To Reproduce
Steps to reproduce the behavior:

1. Opened the following project in vs code via; "Remote-Containers: Open repository in container"
   https://github.com/akutruff/conway-life-react-redux

In container terminal:

cd app
yarn install
yarn start

2. Run debugger. Close page either via "x" on chrome or stopping in the debugger.

3. Reopen chrome.

Log File
vscode-debugadapter-1.json.gz

VS Code Version: 1.48.2

Additional context
I have tried setting up a separate debug profile. Other people experiencing this problem used to use a command line flag that Chrome has since removed. This has been tried:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
            "userDataDir": false,
            "runtimeArgs": [
                "--profile-directory=debug-profile",
                "--noerrors", "--disable-session-crashed-bubble", "--disable-infobars"
              ],
            "trace": true
        }
    ]
}

[akutruff]

LICENSE.txt

Added! Thanks for pointing that out.

[connor4312]

Thanks for the issue! Can you try this in tomorrow's VS Code Insiders? I've done a lot of refactoring around the remote browser launching mechanics earlier this month and want to make sure the problem still exists before diving in.

[akutruff]

Will do, and I'll report back. Thanks!

…

On Wed, Aug 26, 2020 at 12:25 PM Connor Peet ***@***.***> wrote: Thanks for the issue! Can you try this in tomorrow's VS Code Insiders <https://code.visualstudio.com/insiders/>? I've done a lot of refactoring around the remote browser launching mechanics earlier this month and want to make sure the problem still exists before diving in. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#723 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGVMQKAWVG5UDSMF33ALTLSCUZQPANCNFSM4QLA75KQ> .

[akutruff]

Still an issue on Insiders.

At first the problem was not reproducing. While debugging I switched chrome profiles in order to get the react/redux extensions loaded. Now it won't stop repeating the "Restore pages" problem.

The first time I launched it was with:

    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
        }

Switched Chrome profiles. Started getting the problem at this point after I started debugging again.

I then also tried changing the launch.json to the below to get the "debug-profile" loaded:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
            "userDataDir": false,
            "runtimeArgs": [
                "--profile-directory=debug-profile"
              ],         
        }
    ]
}

[akutruff]

Interesting developments. I made it go away but only after some manual surgery, and may have found another issue. It looks like [Object Promise] is in the profile paths for some reason. I'm assuming that's a bug.

It looks like the debugger is generating and using this path for things:
C:\Users\andyk\AppData\Local\Programs\Microsoft VS Code Insiders\[object Promise]

I deleted the debug-profile subdirectory in the above path and started fresh.

Using this launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
        }
    ]
}

The "Restore Pages" dialog went away. Cool.

However, I then added userDataDir set to false.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "chrome",
            "request": "launch",
            "name": "Launch Chrome against localhost",
            "url": "http://localhost:3000",
            "webRoot": "${workspaceFolder}",
            "userDataDir": false,               
        }
    ]
}

restarted debugging and then "Restore pages" started occuring again.

Looking at chrome://version

Google Chrome | 84.0.4147.135 (Official Build) (64-bit)
-- | --
Revision | c42bd09b3f24da1698d71d3b4f57402137163566-refs/branch-heads/4147@{#1102}
OS | Windows 10 OS Version 2004 (Build 19041.450)
JavaScript | V8 8.4.371.23
Flash | 32.0.0.414 C:\Users\andyk\AppData\Local\Programs\Microsoft VS Code Insiders\[object Promise]\PepperFlash\32.0.0.414\pepflashplayer.dll
User Agent | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36
Command Line | "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --user-data-dir="[object Promise]" --disable-background-networking --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-breakpad --disable-client-side-phishing-detection --disable-default-apps --disable-dev-shm-usage --disable-renderer-backgrounding --disable-sync --metrics-recording-only --no-first-run --no-default-browser-check --remote-debugging-pipe --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox --origin-trial-disabled-features=MeasureMemory about:blank
Executable Path | C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path | C:\Users\andyk\AppData\Local\Programs\Microsoft VS Code Insiders\[object Promise]\debug-profile

It appears that the userDataDirectory is still being set to the VS Code path and isn't being respected.
Next, I deleted the debug-profile directory in the VS Code path again. Leaving userDataDir set to false. The dialog has gone away...

[akutruff]

More data - So after I installed the React tools Chrome extension while the debugger is running, and relaunched the debugger the "Restore Pages" dialog started appearing again. : (

[akutruff]

As the ultimate way to manually recover from this, I went into the Preferences file in the debug-profile directly, and manually changed the exit_type field from Crashed to Normal and now I can debug with extensions installed without the popup.

Found on : stackexchange

It only lasts temporarily it seems and the problem will start back again

[connor4312]

Someone else found the [object Promise], I fixed that here: microsoft/vscode-js-debug-companion#7

[connor4312]

For some reason, I couldn't repro before, but tried again today and was able to do so easily. Looks like we were tearing down the session (including killing the browser) when its stdout closed, but at least on windows this caused us to kill Chrome in the midst of it shutting down, which it registered as a crash. Instead, wait for the process to actually exit.

[roblourens]

Still getting this, is that extension published?

[connor4312]

hm, I can't repro on any of my machines. The extension is published and built-in on VS Code Insiders. Did you open a new workspace folder? To make sure you didn't have any old 'crashed' signals lying around...

[akutruff]

I tried starting clean a couple of times. All the above attempts of cleaning out crashes did not help. Did you try this with multiple chrome profiles on the machine?

[connor4312]

@akutruff are you using the most recent build of Insiders?

[akutruff]

I started completely fresh with latest insiders, it was still reproducing at first, but now maybe is okay?

I did the following:

1. Then, I deleted the UUID directories in: C:\Users<My User Name>\AppData\Roaming\Code - Insiders\User\workspaceStorage. Problem went away.
2. I then installed react dev tools and redux dev tools.
3. Closed Chrome. I relaunched debugger. I got the "Restore Pages" prompt again.
4. I closed and relaunched debugger , and now it's working without "Restore Pages." showing up.

[connor4312]

I've pushed a change to try to wait for the process to gracefully exit, killing it if it doesn't in 1s. Normally we issue a Browser.close() (given our CDP pipe is still alive) so generally Chrome should be able to clean itself up. I'll bump this for the next Insiders build, let me know if you continue to hit this.

[pcjmfranken]

I was encountering this issue today with VSCode 1.52.1 and Debugger for Chrome extension 4.12.11.

Adding "browserLaunchLocation": "ui" to the launch config seems to have fixed the "restore pages" issue for me. It does take a few seconds to start up the browser with this setting though.

This issue has only ever occurred for me when launching Chrome through a debug launch config. I have never had the restore pages popup when launching a Chrome debug window through the commandline. It also seemed to happen more often after having stopped the previous Chrome debug session through the VSCode UI stop button (or shift+f5), rather than quitting Chrome through the application menubar.

Current config (relevant parts):

    {
      "name": "Launch Chrome",
      "type": "pwa-chrome",
      "request": "launch",
      "browserLaunchLocation": "ui",
      "url": "http://localhost:3000",
      "userDataDir": "${workspaceFolder}/.vscode/debug-profile-chrome",
      "webRoot": "${workspaceFolder}",
      "skipFiles": ["<node_internals>/**"]
    }

Probably unrelated but who knows: That same UI stop button also seems to gracelessly kill node processes that were launched from a launch config, sometimes resulting the following session to fail with a segfault error.

Quiting through the VSCode UI: zsh: killed /usr/bin/env [userdir]/.nvm/versions/node/v14.15.4/bin/node --inspect
Quiting by doing a ctrl+c in the terminal: Waiting for the debugger to disconnect...

[navels]

I was encountering this issue today with VSCode 1.52.1 and Debugger for Chrome extension 4.12.11.

Adding "browserLaunchLocation": "ui" to the launch config seems to have fixed the "restore pages" issue for me. It does take a few seconds to start up the browser with this setting though.

You are my hero