Firefox doesn't offer the Permissions API in the devtools

[fregante]

Somewhat related to https://bugzilla.mozilla.org/show_bug.cgi?id=1493396 (sidebar, not fixed) and refined-github/refined-github#840 (comment) (preferences page, fixed)

Possible solutions:

• Direct them to the options page to add a permission (a button on the current page isn't permitted, unless we include an iframe pointing to an extension page)
• webext-domain-permission-toggle for Firefox users + copy this guide into <PermissionPane>, without having to go through the options page.

---

I think the webext-domain-permission-toggle approach makes sense for Firefox issues. We'll just need to style the guide to match the existing style within the devtools

Originally posted by @twschiller in #490 (comment)

[fregante]

It seems that permissions.request is used when saving an extension:

But:

• I don’t think .request works this way in Chrome (unless the trusted event manages to travel through 2 async/promised callbacks)
• Why are permissions being requested/checked at saving time?

If checking for permissions is required and it can be changed to a simple .contain, what do you think about lifting permissions.contains into the background?

[twschiller]

Why are permissions being requested/checked at saving time

It requests permissions at save time so that the extension will work on new tabs immediately

The context here is that the user might have added bricks that require additional permissions (e.g., to make network calls, notifications), etc.

Otherwise the user has to go into the Active/Installed extensions page of the extension and click "Grant Permissions" on the extension

unless the trusted event manages to travel through 2 async/promised callbacks

In my tests, the code was working as-is. I don't recall Chrome having issues tracing trusted events for permissions requests

what do you think about lifting permissions.contains into the background

I think it makes sense to lift the permissions check to the background.

If Firefox can't support requesting permissions from the dev tools, we should show the Firefox users a modal that they need to go to the extension options page to finish granting permissions (and provide an option to open the options page)

I can help with the React part of the modal

[fregante]

If Firefox can't support requesting permissions from the dev tools, we should show the Firefox users a modal that they need to go to the extension options page to finish granting permissions (and provide an option to open the options page)

I think this doesn't need a Firefox-specific UI. I suggest:

• Letting "permissions.request on save" fail silently in Firefox

• Showing a "This brick requires extra permissions" in the editor (as an inline notice) and in the Active Bricks options page

  

• Adding a Permissions tab in the brick workshow so that it can be shown/requested at any time

  

• Pointing the "Grant permissions" button to this tab in the options

[twschiller]

and in the Active Bricks options page

PixieBrix already have an affordance for this. You can test it by creating an extension that requires permissions, and then revoking the permissions from the Setting page

Adding a Permissions tab in the brick workshop

I don't think this is necessary if: 1) we have the grant permissions button on the main options page, 2) IIRC, when you click "Update Brick" it automatically does the permissions request/check

Pointing the "Grant permissions" button to this tab in the options

Which screen/interface are you referring to on this?

Letting "permissions.request on save" fail silently in Firefox

I think there needs to be some indication that the brick won't show up in other tabs once you save it. We can't expect users to know they need to open the options page. Is this what you were referring to with 'Pointing the "Grant permissions" button to this tab in the options'?

[fregante]

Pointing the "Grant permissions" button to this tab in the options

Which screen/interface are you referring to on this?

In the brick editor

Adding a Permissions tab in the brick workshop

I don't think this is necessary if: 1) we have the grant permissions button on the main options page,

So can we point that Grant Permission button to that page, if it's easily linkable-to (e.g. if there are a lot of bricks, will it be noticeable in the list?)

Letting "permissions.request on save" fail silently in Firefox

I think there needs to be some indication that the brick won't show up in other tabs once you save it.

This is the indication:

• Showing a "This brick requires extra permissions" in the editor (as an inline notice)

[fregante]

In short:

1. User adds Notifications brick in the editor

2. "Grant Permissions" button and "This brick requires extra permissions" notice appear, both of which already appear in some cases:

   

3. "Save" won't cause any errors, or will just show a similar message to what we show when they click "Deny" on Save:

   

The user:

• knows they must grant additional permissions because there's an inline notice + toast on save
• can grant permissions by clicking Grant Permissions in both browsers, but:

  • in Chrome it will just call .request

    

  • in Firefox it will open the options page where another Grant Permission will appear, ideally the Active Bricks page since it already has that exact button

    

[fregante]

There's only one problem with the last line in my previous comment: Active Bricks will not appear until the brick has been saved, so it's not a complete solution to the problem. We might still need a custom UI as you initially suggested, and I still suggest it to be part of the brick options UI:

This would double as a view that lists a brick’s permissions to the user, which I think is your intention at some point:

1. Main reason: I want the brick to declare the permission because that then allows us in the future to use permissions to inform users what behavior a blueprint they install

Originally posted by @twschiller in #726 (comment)

[twschiller]

This would double as a view that lists a brick’s permissions to the user

Yes, I think we will want to add the permissions listing tab. However, I will probably put the permissions button more prominently up by Update Brick. The "Export Blueprint" button we'll likely be moving, e.g., to a dropdown, as its not commonly used

"Grant Permissions" button and "This brick requires extra permissions" notice appear, both of which already appear in some cases

I forgot about that case - the "Grant Permissions" button in the effect/options section is if we need to make network requests to fetch the available configuration options (for editing)

I need to think this over, but we would probably want to open a new options tab that has a button the user can click to grant permissions to the particular domain

in Firefox it will open the options page where another Grant Permission will appear,

Due to what you mentioned (i.e., the brick won't be saved yet necessarily at the time of the request), I suspect we may just want to open the options page to a "request permissions" page where the permissions to request are passed along via URL params. That UX would also be a solution for granting permissions for the purpose of configuring the brick

@fregante If the approach of a PixieBrix permissions request page with a URL param for the requested permissions seems good to you, I will go ahead and create that page so you can incorporate it into the flow

[fregante]

Yes that sounds like a good idea. Do you think it makes sense to show this transitional piece of UI in the Options page though? Or would it make more sense as a standalone page? Perhaps even something that can be opened in a popup similarly to what I had originally suggested for webext-alert, except with local HTML.

[fregante]

I finally opened a bug report for this https://bugzilla.mozilla.org/show_bug.cgi?id=1493396

[twschiller]

It looks like the issue is also set for discussion in w3c this week: w3c/webextensions#40