Unable to open the Extensions page with --start-url when running in Chrome

[ghostwords]

Is this a feature request or a bug?

Bug

What is the current behavior?

Running an extension in Chrome with --start-url "chrome://extensions" (or "about:extensions") fails to open the Extensions page. (The extensions page is useful for inspecting your extension's background page.)

Using --start-url to open about:debugging does work in Firefox.

Versions

Chrome 84
web-ext 5.0.0

[rpl]

It seems that Chrome does ignore chrome://extensions (also other chrome:// urls, like chrome://version) passed on the command line, e.g. executing on the command line

google-chrome http://developer.mozilla.org

does start Chrome with the given url loaded in the first tab

On the contrary:

google-chrome chrome://version

does start Chrome but it doesn't load that chrome url in the first tab.

I have the feeling that this may be an intended behavior, I briefly looked if Chrome does provide a command line flag to override this behavior, but at the moment I haven't spotted any that may be related.

We may have to close this as a wontfix if we don't have a way to tell Chrome to allow chrome:// urls as start urls, but for now I'm keeping this open to take another look and think a bit if there may be other options to achieve that.

[Rob--W]

Chrome extensions can open many chrome:-pages.

[rpl]

Chrome extensions can open many chrome:-pages.

that's true, and I just verified that chrome://extensions is one of those that can be opened successfully using chrome.tabs.create, and so one option to fix this in web-ext would be to special case the chrome://extension url (or any chrome url) in the chrome extension runner and make the companion extension that we install automatically to auto-reload the target extension able to call chrome.tabs.create for us.

[Rob--W]

I'll mentor this bug.

[DeepikaKaranji]

Hi @Rob--W !

May I work on this bug?
If yes, can I have the STR?
I went through https://extensionworkshop.com/documentation/develop/getting-started-with-web-ext/, but a little more clarity on where chrome comes into the picture will be more helpful.
Thanks!

[Rob--W]

@DeepikaKaranji Taking a step back, the core of the issue is that trying to open chrome://extensions doesn't work from the command line. Extensions are able to do so though, by passing that url to chrome.tabs.create.

web-ext uses a helper extension (via createReloadManagerExtension) in Chrome to support its functionality. To resolve this bug you have to forward the URL to that helper extension instead of the command line. The relevant source code is around these lines:

web-ext/src/extension-runners/chromium.js

Lines 153 to 227 in 9353e26

	// Create the extension that will manage the addon reloads
	this.reloadManagerExtension = await this.createReloadManagerExtension();
	// Start chrome pointing it to a given profile dir
	const extensions = [this.reloadManagerExtension].concat(
	this.params.extensions.map(({sourceDir}) => sourceDir)
	).join(',');
	const {chromiumBinary} = this.params;
	log.debug('Starting Chromium instance...');
	if (chromiumBinary) {
	log.debug(`(chromiumBinary: ${chromiumBinary})`);
	}
	const chromeFlags = [...DEFAULT_CHROME_FLAGS];
	chromeFlags.push(`--load-extension=${extensions}`);
	if (this.params.args) {
	chromeFlags.push(...this.params.args);
	}
	// eslint-disable-next-line prefer-const
	let {userDataDir, profileDirName} =
	await ChromiumExtensionRunner.getProfilePaths(
	this.params.chromiumProfile);
	if (userDataDir && this.params.keepProfileChanges) {
	if (profileDirName
	&& !await ChromiumExtensionRunner.isUserDataDir(userDataDir)) {
	throw new Error('The profile you provided is not in a ' +
	'user-data-dir. The changes cannot be kept. Please either ' +
	'remove --keep-profile-changes or use a profile in a ' +
	'user-data-dir directory');
	}
	} else if (!this.params.keepProfileChanges) {
	// the user provided an existing profile directory but doesn't want
	// the changes to be kept. we copy this directory to a temporary
	// user data dir.
	const tmpDir = new TempDir();
	await tmpDir.create();
	const tmpDirPath = tmpDir.path();
	if (userDataDir && profileDirName) {
	// copy profile dir to this temp user data dir.
	await fs.copy(path.join(
	userDataDir,
	profileDirName), path.join(
	tmpDirPath,
	profileDirName),
	);
	} else if (userDataDir) {
	await fs.copy(userDataDir, tmpDirPath);
	}
	userDataDir = tmpDirPath;
	}
	if (profileDirName) {
	chromeFlags.push(`--profile-directory=${profileDirName}`);
	}
	let startingUrl;
	if (this.params.startUrl) {
	const startingUrls = Array.isArray(this.params.startUrl) ?
	this.params.startUrl : [this.params.startUrl];
	startingUrl = startingUrls.shift();
	chromeFlags.push(...startingUrls);
	}
	this.chromiumInstance = await this.chromiumLaunch({
	enableExtensions: true,
	chromePath: chromiumBinary,
	chromeFlags,

With those two code snippets, you can probably get started. Let me know if there are still questions!

[caitmuenster]

Hey @DeepikaKaranji, how's it going with this issue?

[DeepikaKaranji]

Hello @caitmuenster , I was AFK for a bit, I've set up the environment, and I have gotten started with this issue yesterday.

[DeepikaKaranji]

@Rob--W

How I thought I'll approach this was:

1. See what gets called when I run google-chrome http://developer.mozilla.org from command line.
2. From that, understand which variable exactly holds the URL that is being passed in command line.
3. See where that http URL is getting passed.
4. Find out when the createReloadManagerExtension is actually called.
5. And of course, other in-between things I need check as I work.

What I've understood/ not understood so far:

1. createReloadManagerExtension() is called everytime ChromiumExtensionRunner object is instantiated.
2. bg.js is run as a background task, but I'm not sure where to find bg.js to see what it does, and if I actually need to worry about it.
3. I can see that setEnabled has some extensionID and values in it, which is what I think I should carry the chrome:- URL, but I'm not too clear on why its being passed as a string to setEnabled. I could also use some help in understanding how to log these values to see if chrome:- URL is actually getting passed there when I do eventually write my logic.
   

   web-ext/src/extension-runners/chromium.js

   Lines 312 to 331 in bd2974b

   	const bgPage = `(function bgPage() {
   	async function getAllDevExtensions() {
   	const allExtensions = await new Promise(
   	r => chrome.management.getAll(r));
   	return allExtensions.filter((extension) => {
   	return extension.installType === "development" &&
   	extension.id !== chrome.runtime.id;
   	});
   	}
   	const setEnabled = (extensionId, value) =>
   	chrome.runtime.id == extensionId ?
   	new Promise.resolve() :
   	new Promise(r => chrome.management.setEnabled(extensionId, value, r));
   	async function reloadExtension(extensionId) {
   	await setEnabled(extensionId, false);
   	await setEnabled(extensionId, true);
   	}

4. Can you also please tell me how I can achieve Step-1 in my above approach?
   Thank you.

[Rob--W]

@Rob--W

How I thought I'll approach this was:

1. See what gets called when I run google-chrome http://developer.mozilla.org from command line.

This step is incorrect. I think that the misunderstanding is that you think that you need to change the behavior of how google-chrome [url] is handled. That is not the case; how Chrome handles command-line flags is not something that we can control.

google-chrome http://developer.mozilla.org works, and is not a surprise.
google-chrome chrome://extensions does not, however. That's why we want to filter that URL, and open it via the helper extension (in bg.js) instead. So the part to change is what parameters are passed to the Chrome binary (i.e. without chrome://extensions) and forward the URL in a different way instead (see below).

2. bg.js is run as a background task, but I'm not sure where to find bg.js to see what it does, and if I actually need to worry about it.

bg.js is written to a temporary directory that is loaded as a background page of the helper extension. That directory is loaded as an extension via the --load-extension flag for Chrome.

3. I can see that setEnabled has some extensionID and values in it, which is what I think I should carry the chrome:- URL, but I'm not too clear on why its being passed as a string to setEnabled. I could also use some help in understanding how to log these values to see if chrome:- URL is actually getting passed there when I do eventually write my logic.

setEnabled is not the interesting part. Rather, the part that handles the communication between the web-ext application and the helper extension is. A WebSocket is used for communication, and the message is received and handled at the ws.onmessage listener in bg.js. I suggest to look at how the (only) existing message is sent (you can search/grep for the message type in the code base) to try and understand how the communication happens.

[caitmuenster]

Hey @DeepikaKaranji, how's it going with this issue?