Chrome扩展程序-寻求新权限

Question

I have a chrome extension already in the store to which I need to add more permissions as I want to apply it to more websites. But putting them into the permissions array disables the extension and the only indication that it requires new permissions is under the hamburger menu, which is entirely useless.

Here is the original, which seems to have an implied " https://mail.google.com " permission due to it being in the content_scripts object:

 { "manifest_version": 2, "name": "My Extension", "short_name": "Extension", "version": "1.5.16", "description": "Description here", "homepage_url": "https://test.com/", "icons": { "16": "icon16.png", "48": "icon48.png", "128": "icon128.png" }, "content_scripts": [ { "matches": [ "https://mail.google.com/*" ], "js": [ "injector.js" ], "css": [ "style.css" ] } ], "web_accessible_resources": [ "app.js", "libs.js" ] } 

In a perfect world I'd just add additional "content_scripts" objects, but this disables the extension due to the implied permission to the new website domain.

Putting "optional_permissions": [" https://hangouts.google.com "] still disables the plugin and doesn't notify the user.

If I put any code at all into a background script, say something that accesses chrome.tabs in any way... BOOM! It's implied permission and the extension is disabled.

How should I be going about getting new permissions without disabling the extension? Popups to ask for permission would be a perfect solution, but that's not what I'm being offered.

Answer 1

Setting aside the question of content scripts, in most cases optional permissions are not worth it for patching a list of permissions from one fixed list to another.

You'll make both existing and new users go through runtime permissions dialog that's perplexing to new users.

The real purpose of optional permissions is to allow the users to choose among domains not known at runtime.

It's best to bite the bullet and risk disabling of the extension.

If you wish, you can publish a second extension with the new permissions, make the first unlisted, and publish an update that urges users to install the new extension.

Some users might prefer this, some might instead be more annoyed - it's a lose-lose sitation from the start, you won't retain all your users. With the migration route you will lose the accumulated rating in the store, though.

---

Adding a content script is, indeed, an implicit grant of host permission. And the declarative API to change content script configuration at runtime never became supported/stable .

So if you absolutely resolved to go the optional permissions route, you'll need to (inefficiently, with restrictions) do programmatic injection .

Answer 2

In addition to the existing answer (which is totally valid), I'll suggest how to handle optional permissions in case you decide to avoid adding new permissions in manifest.json

Programmatic script injection

There's a new contentScripts.register() API that you can use to efficiently register your scripts on new domains after you get the permission.

browser.contentScripts.register({
    matches: ['https://your-dynamic-domain.example.com/*'],
    js: [{file: 'content.js'}]
});

This API is only available in Firefox but there's a Chrome polyfill you can use.

Acquiring new permissions

You can use chrome.permissions.request to let the user add new domains on demand or you can install a module I wrote recently ( webext-domain-permission-toggle ) to provide a simple UI to toggle permissions on any domains.

When used together with webext-dynamic-content-scripts , you can add any domain and the module will automatically register your existing content_scripts on them.