Auto grant extension perms when invoking "web-ext run"?

[onpaws]

Is this a feature request or a bug?

Feature request (I think).
If this already exists, apologies, feel free to close.

What is the current behavior?

1. Invoke web-ext run with a permissionless v3 extension, e.g. this
2. Browse to a matching domain, e.g. https://www.mozilla.org/
3. Observe the extension icon dot indicating "permissions needed":

What is the expected or desired behavior?

When developing an extension, it's annoying to have manual steps in the feedback loop like this. It would be nice to have that permission automatically enabled, especially given it's an ephemeral dev browser instance anyway.

Possible?
i.e. like this

Alternatively, if this is not in scope for web-ext, is there some way to set state in e.g. the Firefox profile?

(obviously it should persist across runs -- I noticed the extensions perms seem to reset every time. Just guessing but I wonder if the profile, which I'm assuming is where these user-entered perms get persisted, can be manually specified ahead of time.)

Version information (for bug reports)

• Firefox version: 119
• Your OS and version: macOS 13.6
• node v18.18.2
• npm 9.8.1
• web-ext 7.8.0

[onpaws]

I thought about this problem a bit more today and it seems like if I could track down where the extension permission state lives, which I guess should be in the profile (?), maybe I could invoke web-ext run with a profile where the extension is "pre-approved" and sidestep this.

After digging around the web-ext repo a bit I found this.

pref: {
        describe:
          'Launch firefox with a custom preference ' +
          '(example: --pref=general.useragent.locale=fr-FR). ' +
          'You can repeat this option to set more than one ' +
          'preference.',
        demandOption: false,
        requiresArg: true,
        type: 'array',
        coerce: (arg) =>
          arg != null ? coerceCLICustomPreference(arg) : undefined,
      },

and

'firefox-profile': {
        alias: 'p',
        describe:
          'Run Firefox using a copy of this profile. The profile ' +
          'can be specified as a directory or a name, such as one ' +
          'you would see in the Profile Manager. If not specified, ' +
          'a new temporary profile will be created.',
        demandOption: false,
        type: 'string',
      },

Now I'm trying to figure out if profile or pref is the best entrypoint towards "pre-approving" the extension 🤔

web-ext run --firefox-profile=/Users/paws/Developer/firefox-profile-webextension-dev --keep-profile-changes
Running web extension from /Users/paws/Developer/webextensions-examples/borderify
Use --verbose or --devtools to see logging
Installed /Users/paws/Developer/webextensions-examples/borderify as a temporary add-on
The extension will reload if any source file changes
Press R to reload (and Ctrl-C to quit)

Seeing "temporary add-on" makes me think I will need to assign a stable ID in manifest.json.
Plenty to learn on this, if anyone has insight would be appreciated :)

[onpaws]

Success! 🥳

This approach I landed on still requires a manual GUI step, but it's only once instead of N times.
Here are the steps that worked for me:

1. In manifest.json, assign a value to browser_specific_settings.gecko.id. This step seems to be crucial.

...
"browser_specific_settings": {
    "gecko": {
      "id": "[email protected]",
    }
  },
...

2. Invoke web-ext with the firefox-profile and keep-profile-changes flags. (Presumably after approving the extension, you could drop keep-profile-changes.)
   web-ext run --firefox-profile=/absolute/path/to/profile --keep-profile-changes
   As best as I can tell this is necessary because otherwise web-ext seems to use a new ephemeral profile, which we want to avoid because setting extension perms on every run gets old real fast.

3. Click this:
   

4. You're done. Subsequent web-extinvocations should honor the permissions you just set.

NB, I'm not 100% sure but you may need to first invoke
web-ext run --firefox-profile=/absolute/path/to/profile --profile-create-if-missing
before step 2, to generate a new profile. It seemed like a profile got created in my case without this command, so YMMV.

A cooler approach would be avoiding the GUI step comletely, e.g. `web-ext --allow-all-extensions" but this is good enough for today.

Hope this helps someone else dipping their toes into the WebExtension v3 world.
Marking closed.

[rnwst]

You saved me hours of my time, thank you very much! At first I couldn't work out why my content script wasn't loading, until I realised that it required permissions. Then the question was how to keep those permissions enabled permanently, which you have answered above.

I suggest reopening this as it is likely we are not the only ones having this problem, and in my view this is unexpected behavior - web-ext run really should take care of setting the right permissions by itself!

[Rob--W]

To improve the developer experience, I created a ticket to add a helpful message when a MV3 extension is loaded: #2980

The request also includes a full description on implementing it, and patches are welcome!

[onpaws]

Glad to hear it helped you @rnwst! Definitely had to jump through hoops to figure this out 😅

Caveat, I haven't tried it personally, but after making this issue, I read up on Firefox Developer Edition and learned it apparently relaxes certain extension perms already. Not sure if it additionally addresses this particular friction, which presumably most MV3 extension developers will face. Would be nice! :)

[Rob--W]

The deved exceptions above do not help with working around this issue. All it does is allowing unsigned extensions to be used AND temporarily loaded extensions to use privileged code. Do not use these to install untrusted extensions, because they put your whole system (outside of Firefox) at risk.

[onpaws]

AND temporarily loaded extensions to use privileged code.

Thanks, helpful info!

Your comment made me curious if extensions can shell out similar to other commands like xp_cmdshell.

I found a current Chrome doc that describes Native Messaging, but a search also revealed there is (or used to be? I didn't try it) chrome.shell.Command. Fascinating.