Browser profile directories (Chrome and Firefox) are not deleted after web-ext disconnects

[darkred]

Is this a feature request or a bug?

Bug

(related: #1981)

What is the current behavior?

I use web-ext to build and test an extension, Refined GitHub. It's located in C:\refined-github .

Inside the above directory (cd C:\refined-github),
I use npm run start:firefox (web-ext run) which launches Firefox.
or npm run start (web-ext run --target=chromium) which launches Chrome stable/canary .

While the Firefox/Chrome browser instance is running,
I've noticed that a mozilla-temp-files/tmp-web-ext directory is created in %temp% .

Additionally, a new temporary profile in created in :

• Firefox: C:\refined-github\test\web-ext-profile
• Chrome stable: C:\refined-github\test\web-ext-profile\Default
• Chrome canary: C:\Users\Kostas\AppData\Local\Google\Chrome SxS\Application\test\web-ext-profile\Default

i.e. the 1st and 2rd are created inside the current directory C:\refined-github,
while the 3nd is created inside Canary installation path.

Now, when web-ext disconnects (either because I press Ctrl+C in console, or just close the browser window),
then the mozilla-temp-files/tmp-web-ext directory in %temp% is indeed removed,
but the profile directory (mentioned above) and its contents all remain,
and if I re-launch npm run start it re-uses the profile from before.

What is the expected or desired behavior?**

Is this the expected behavior?
Shouldn't these new temporary profile directories be removed when web-ext disconnects?
I'd expect the temporary profile to be removed on disconnect. This would justify its "temporary" name, right?

Especially about the Canary temporary profile: it's created inside the Canary installation directory (see path above),
but it's not listed in Canary's 'Manage profiles' list, so the user has to remove it manually.

Version information (for bug reports)

• Firefox version: 86
• Chrome version: 89 stable, 91 canary
• Your OS and version: Windows 10 x64
• Paste the output of these commands: Node: 15.11.0, npm 7.6.0, web-ext 6.0.0

node --version && npm --version && web-ext --version

[rpl]

@darkred thanks for reporting this to us, the additional details looks pretty useful to look into it.

@Rob--W would you mind to take a look into this? it looks something that may be kind of related to that discussion about --user-data vs. --profile-dir in Chrome cli options (from #1909 and #1920)

[Rob--W]

web-ext run does not create directories in your directory by default. The refined-github project that you're referring to has configured web-ext to persist changes, via the "keepProfileChanges": true option at https://github.com/sindresorhus/refined-github/blob/ef783da57e70e82295954cfe932791a4b62f159f/package.json#L134-L136

...
	"webExt": {
		"sourceDir": "distribution",
		"run": {
			"keepProfileChanges": true,
			"firefoxProfile": "./test/web-ext-profile",
			"chromiumProfile": "./test/web-ext-profile",
			"startUrl": [
				"github.com"
			]
		}
	}
}

Can you run web-ext with the --verbose flag, so that we can see the exact command that started Chrome?
And also the content of chrome://version , particularly "Command Line", "Executable Path" and "Profile Path"

[darkred]

Thank you for clarifying!

Here (using Chrome Canary) :

web-ext with the --verbose flag

C:\refined-github>web-ext run --target=chromium --verbose

[program.js][info] Version: 6.0.0
[program.js][debug] Discovering config files. Set --no-config-discovery to disable
[config.js][debug] Discovered config "C:\Users\Kostas\.web-ext-config.js" does not exist or is not readable
[config.js][debug] Discovered config "C:\refined-github\web-ext-config.js" does not exist or is not readable
[program.js][info] Applying config file: .\package.json
[config.js][debug] Loading JS config file: "C:\refined-github\package.json" (resolved to "C:\refined-github\package.json")
[config.js][debug] Looking for webExt key inside package.json file
[config.js][debug] Calling coerce() on configured value for sourceDir
[cmd/run.js][info] Running web extension from C:\refined-github\distribution
[util/manifest.js][debug] Validating manifest at C:\refined-github\distribution\manifest.json
[util/temp-dir.js][debug] Created temporary directory: C:\Users\Kostas\AppData\Local\Temp\tmp-web-ext--7832-7hsYh713yShB[extension-runners/chromium.js][debug] Creating reload-manager-extension in C:\Users\Kostas\AppData\Local\Temp\tmp-web-ext--7832-7hsYh713yShB\reload-manager-extension-1616004673515
[extension-runners/chromium.js][debug] Starting Chromium instance...
[cmd/run.js][info] The extension will reload if any source file changes
[util/file-filter.js][debug] Resolved path **/*.xpi with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\*.xpi
[util/file-filter.js][debug] Resolved path **/*.zip with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\*.zip
[util/file-filter.js][debug] Resolved path **/.* with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\.*
[util/file-filter.js][debug] Resolved path **/.*/**/* with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\.*\**\*
[util/file-filter.js][debug] Resolved path **/node_modules with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\node_modules
[util/file-filter.js][debug] Resolved path **/node_modules/**/* with sourceDir C:\refined-github\distribution to C:\refined-github\distribution\**\node_modules\**\*
[watcher.js][debug] Watching C:\refined-github\distribution for changes
[extension-runners/index.js][info] Press R to reload (and Ctrl-C to quit)

And

chrome://version

Google Chrome	91.0.4449.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Revision		0034c5812d1a49d952fca7f53d2eca76a31abe17-refs/branch-heads/4449@{#1}
OS				Windows 10 OS Version 2009 (Build 19042.867)
JavaScript		V8 9.1.140
User Agent		Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4449.0 Safari/537.36
Command Line	"C:\Users\Kostas\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --remote-debugging-port=54883 --user-data-dir=./test/web-ext-profile --disable-features=TranslateUI --disable-component-extensions-with-background-pages --disable-background-networking --disable-sync --metrics-recording-only --disable-default-apps --no-default-browser-check --no-first-run --disable-backgrounding-occluded-windows --disable-renderer-backgrounding --disable-background-timer-throttling --force-fieldtrials=*BackgroundTracing/default/ --load-extension="C:\Users\Kostas\AppData\Local\Temp\tmp-web-ext--7832-7hsYh713yShB\reload-manager-extension-1616004673515,C:\refined-github\distribution" --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=SecurePaymentConfirmation github.com
Executable Path	C:\Users\Kostas\AppData\Local\Google\Chrome SxS\Application\chrome.exe
Profile Path	C:\Users\Kostas\AppData\Local\Google\Chrome SxS\Application\test\web-ext-profile\Default
Variations		da89714-4ad60575   5e3a236d-59e286d0

i.e.

[Rob--W]

It looks like the --user-data-dir=./test/web-ext-profile path is resolved relative to the working directory of Chrome. On Linux, the correct directory is selected, but on Windows, it seems that the path is resolved relative to the application.

@darkred If you change ./test/web-ext-profile to .\\test\\web-ext-profile in package.json, do you see any different results?

To resolve this bug, I guess that we can canonicalize the relative path (turn it into an absolute path before use).

It is a bad idea to use a subdirectory of the current directory as the profile directory though... The extension will probably reload repeatedly, because changes are detected in the current directory.

[darkred]

@darkred If you change ./test/web-ext-profile to .\\test\\web-ext-profile in package.json, do you see any different results?

Correction:
with that change,
the directory is now indeed created inside %temp%,
in fact the directories created are 2:
the one nearly empty (2 files, 1 KB), the other is large (lots of files, 66 MB) :

screenshots

After web-ext disconnects, the small directory gets removed,
but unfortunately the large one remains (even though I changed keepProfileChanges to false in package.json):

screenshot

My modified package.json section :

[darkred]

@Rob--W Based on my previous comment, shouldn't the large folder in %temp% also be deleted after web-ext disconnects?
(I changed keepProfileChanges to false in package.json)

[Rob--W]

@Rob--W Based on my previous comment, shouldn't the large folder in %temp% also be deleted after web-ext disconnects?
(I changed keepProfileChanges to false in package.json)

That may be part of #1981.