1892655 - browser.permissions.request might be unintentionally too difficult to use

Status: RESOLVED DUPLICATE of bug 1398833

(WebExtensions :: General, enhancement, P3)

Description

[Adam Baxter]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0

Steps to reproduce:

If I have a v3 WebExtension set up with optional_permissions and a script loaded from my options_ui page along the following lines

async function getPermissionsObjectForCurrentWindow() {
tab = await browser.tabs.query({currentWindow: true, active: true})
url = tab[0].url;
console.log(url);

return [url];
}

document.addEventListener('DOMContentLoaded', function () {
var clickRequestPermissions = async function (e) {
let perms = {
"origins": await getPermissionsObjectForCurrentWindow(),
"permissions": ["webRequest", "webRequestFilterResponse"]
}
await new Promise((resolve, reject) => { browser.permissions.request(perms), resolve });
};

document.getElementById("btnRequestPermissions").addEventListener("click", clickRequestPermissions.bind(this))
});

Then I get "permissions.request may only be called from a user input handler" when I click btnRequestPermissions - clearly a "user input handler"

If I make no other calls in my clickRequestPermissions function, i.e.

let perms = {
"origins": ["https://example.com"]
"permissions": ["webRequest", "webRequestFilterResponse"]
}

Then it works.

See also https://stackoverflow.com/a/47729896

Actual results:

Uncaught (in promise) Error: permissions.request may only be called from a user input handler
clickRequestPermissions moz-extension://7043c3dd-890b-46ae-a746-28176d81bcd9/js/scripts.js:23
clickRequestPermissions moz-extension://7043c3dd-890b-46ae-a746-28176d81bcd9/js/scripts.js:23
async* moz-extension://7043c3dd-890b-46ae-a746-28176d81bcd9/js/scripts.js:26
EventListener.handleEvent* moz-extension://7043c3dd-890b-46ae-a746-28176d81bcd9/js/scripts.js:17

Expected results:

While I appreciate Firefox trying to protect me here, I note that most of my current extensions request either permissions on all pages or similarly broad permissions at install time, and don't make use of optional_permissions.

My concern is that if it is too tricky to use optional_permissions then extensions won't use it at all.

For my own toy extensions, I can request permissions on all pages but I'd really like to be able to have the extension only running on pages I've explicitly allowed it to!

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

Would you be able to attach a test extension with the described behavior so I can check it as well? Thank you !

Additionally, from reading the report, I assume that you are requesting an enhancement to the feature and not signaling a defect. As such, I’ll change the report to enhancement, but do revert the changes in case I interpreted it mistakenly.

Comment 3

[Adam Baxter]

Attachment: permissions-bug-test.zip

Comment 4

[Adam Baxter]

Hi Alex, I have attached an extension that should reproduce this.
I disagree that this is an enhancement request. At the very least, it should be documented that the "user input handler" requirement is very strict.

Comment 5

[Alex Cornestean]

Hello Adam and thank you for the test extension !

I’ve checked the extension out on the latest Nightly (127.0a1/20240424093459), Beta (126.0b5/20240424091756) and Release (125.0.2/20240419144423) under Windows 10 and Ubuntu 22.04 LTS and the behavior is the same across the board.

Clicking the “Works” button will produce an additional pop-up for allowing or denying the optional permission which the user must interact with in order to allow/deny the optional permission. This surely counts as a clear user input.

On the other hand, clicking the “Does not work” button, which I assume tries to grant the optional permission directly, does not produce that additional pop-up for allowing/denying the optional permission. The fact that there is no additional prompt is considered that the user had no input in the matter and throws the error in the console, even though the user clicked the extension pop-up button in the first place.

Yet again, I’m not sure this is a defect, and I’ll NeedInfo one of our developers to shed some light on this.

Comment 6

[Adam Baxter]

Neither button tries to grant the permission directly - both call the same code, but there is some async work done in the function used by the "Does Not Work" button.

The permission popup is generated by the browser. I'm not trying to bypass anything here.

My original usecase was to have an extension use the activeTab permission and then use optional permissions for the rest. However, invoking the tabs query asynchronously appears to cause the issue I am reporting.

This is also reflected in the Stack Overflow link I posted above.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

This is currently the expected behavior, but we are keeping this bug to discuss it further in our design decision triage (and to double-check if we do have another existing bugzilla issue tracking the same underlying issue).

Moving the needinfo to Rob (to add this to the design decision list).

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

Setting P3 in the meantime, to be eventually bumped to higher priority based on the outcome of the design decision discussion.