Provide a way for users to deny permission prompts by default in about:preferences

VERIFIED FIXED in Firefox 59

Status

()

VERIFIED FIXED
2 years ago
a year ago

People

(Reporter: asa, Assigned: prathiksha)

Tracking

(Blocks: 1 bug)

unspecified
Firefox 59
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 59+, firefox57 wontfix, firefox58 wontfix, firefox59 verified)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Many users do not want push notifications and do not want to be prompted by so many websites to enable push notifications. Please provide a global "disable" option for all push notification prompts.
Tina, what do you think about adding a general way to disable the notification prompts entirely in about:preferences?
Flags: needinfo?(thsieh)
Yes, we can add that. Unlike other permissions (such as camera and microphone), blocking notifications won't disable any crucial functions on websites. I'll update the preferences permission spec later :)
Duplicate of this bug: 1313939
Depends on: 1379560
Let's make this bug track the frontend implementation, we'll solve denying the permission globally in bug 1379560.

Tina, do you have the updated spec ready? :)
There have been discussions about Push-specific mitigations in bug 1375683.
See Also: → bug 1375683
Thanks Andrew for sharing more context!

Hey Johann,
Sorry, the spec is still work in progress. The Photon Preferences redesign work is my first priority, so I'll focus on it now and come back to this bug when the Photon redesign is ready.
See Also: bug 1375683
Hi Johann,
Thanks for the waiting. Here is the updated spec with the globally disable notification prompts feature: https://mozilla.invisionapp.com/share/YHBWV6DP8#/243080171_5-7-2_Notifications_Global_Disable

The copy string is currently waiting for a review from our copy writer. I'll update the string here once we have a recommendation. Feel free to ping me if you have any questions :)

Tina
Flags: needinfo?(thsieh)
Core:Permission Manager sounds a better fit for this issue. Do feel free to reset. :)
Component: DOM: Push Notifications → Permission Manager
Duplicate of this bug: 1390783
Let's move this to preferences since the platform work landed in bug 1379560 and we should use this to track putting the deny checkbox into the permission dialog.

Prathiksha, we still have to figure out whether we want to extend this functionality to e.g. Geolocation (bug 1390782) and WebRTC, but we definitely need it for notifications.

Would you like to start implementing a checkbox as shown in comment 7?

Thank you!
Component: Permission Manager → Preferences
Flags: needinfo?(prathikshaprasadsuman)
Product: Core → Firefox
status-firefox57: --- → wontfix
status-firefox58: --- → affected
See Also: → bug 1390782
(Assignee)

Comment 11

a year ago
(In reply to Johann Hofmann [:johannh] from comment #10) 
> Prathiksha, we still have to figure out whether we want to extend this
> functionality to e.g. Geolocation (bug 1390782) and WebRTC, but we
> definitely need it for notifications.
>
> Would you like to start implementing a checkbox as shown in comment 7?

yes. :)
Flags: needinfo?(prathikshaprasadsuman)
(Assignee)

Updated

a year ago
Assignee: nobody → prathikshaprasadsuman
Status: NEW → ASSIGNED
We had a meeting on this and decided to add the proposed toggle to all of Notifications, Geolocation, Camera, and Microphone. I'm adjusting the bug title based on that.

We also said that we'd like to add a modal dialog having the user confirm that they're okay with the potential consequences of their action (breaking websites that rely on this functionality).

Jacqueline, can you help us come up with some copy for these four modal warnings? Let me know if you need help with that.

Thank you!
Flags: needinfo?(jsavory)
Summary: Provide a global "disable all push notifications" preference → Provide a way for users to deny permission prompts by default in about:preferences
(Assignee)

Comment 13

a year ago
We need updated specs to implement all things mentioned in comment 12 and get it into Firefox 58. Tina, can you provide us with the right checkbox and alert box strings, please ? :)

Thanks.
Flags: needinfo?(thsieh)
Apologizes for the late response! I’m unfortunately a little too busy at the moment :) 

After some thought, the warning modal feels a bit overkill in this instance. I think we want to reserve those for really extreme situations and I’m not sure if this qualifies. Instead I think we should add additional information on the checkbox, to hopefully ensure that users are aware of the action they are taking. I’ve attached an image for what I mean, we can certainly adjust the copy. 

Also, I remember we discussed having a method for the user to disable or at least see that the permission is blocked in context. I can’t remember the consensus but I suggest we display it at least in control center, if not the URL bar as well. Ideally this would show only for sites that ask the permission, it might be easier to treat them as a “blocked” state rather than a “hidden” state.

Tina, I’d love to hear your feedback as well, I was also wondering about the string in your original spec, the “Never ask for sending notifications” I tweaked it a bit in my image, let me know what you think.
Flags: needinfo?(jsavory)
Hi Jacqueline,
I like the caption that tells more about how the option works, but I think we also need to let users know that the option may break some websites due to the permission is globally switched off. If we can have a set of clear copy that tells 1) This is a global switch 2) If you turn it off, it may break your browsing experience, then I'll be happy with not having a modal prompt for it.:)

I'll ping Michelle for her input here.
Flags: needinfo?(thsieh) → needinfo?(mheubusch)

Comment 16

a year ago
@Jacqueline - Can you arrange a meeting to discuss this with me and Tina? I'm not sure I see the connection between the issue and the proposed copy in the prefs or understand what the option does - block the request for new permissions or block all [prompts, even those currently permitted.  Thing we should also discuss this copy in context of what appears in the control center.
Flags: needinfo?(mheubusch) → needinfo?(jsavory)
(In reply to mheubusch from comment #16)
> block the request for new
> permissions or block all [prompts, even those currently permitted.

The former.
Michelle, Jacqueline, did this meeting happen and did anything valuable come out of it? I'd love to get this bug into 59...
Flags: needinfo?(mheubusch)
(In reply to Johann Hofmann [:johannh] from comment #18)
> Michelle, Jacqueline, did this meeting happen and did anything valuable come
> out of it? I'd love to get this bug into 59...

Reading this again it sounded a bit brash, it wasn't meant to, thank you for helping us with this :)

Comment 20

a year ago
Jacqueline - Here are two options for the instructional copy (one with the modal, one without - both to address Tina's concern about messaging the potential for breakage):

These websites have requested permission to send notifications. You can specify which sites are allowed to send notifications. You can also block new requests to allow notifications. 


( ) Block new requests to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications, and may affect website performance.

OR 

These websites have requested permission to send notifications. You can specify which sites are allowed to send notifications. You can also block new requests to allow notifications. 


( )Block new requests to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications.

(modal): Blocking notifications may break some website features. OK | CANCEL
Flags: needinfo?(thsieh)
Flags: needinfo?(mheubusch)
Flags: needinfo?(jsavory)
Thank you very much! This copy sounds great to me. I don't think website performance will be affected negatively by blocking permissions, so we can probably leave that part out (unless I'm missing something).

Personally I'd say we should consider not adding a modal until we know from user feedback that too many people are enabling it unaware of the breakage. I wonder if we should just append the modal text to the checkbox information:

( )Block new requests to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications. Blocking notifications may break some website features.

or

( )Block new requests to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications and may break some website features.

Any thoughts?
Agree with Johann that we can tell the possible breaking issues by adding a description under the option without using a modal dialog. For the copy suggestion, I personally think they both work.

Let's see how Michelle think about it :)
Flags: needinfo?(thsieh)

Comment 23

a year ago
My vote: ( )Block new requests to allow notifications
This will prevent any websites not listed above from requesting permission to send notifications. Blocking notifications may break some website features.


thanks, all!
Duplicate of this bug: 1423402

Comment 25

a year ago
I love the implementation mock up in comment 14. Thanks for your hard work!

Comment 27

a year ago
mozreview-review
Comment on attachment 8938165 [details]
Bug 1368744 - Provide a way for users to deny permission prompts by default in about:preferences.

https://reviewboard.mozilla.org/r/208878/#review214840

Thank you for the patch!

I think we're almost there, just a couple of details to sort out, but nothing major as far as I can see.

::: browser/components/preferences/in-content/tests/browser_permissions_dialog.js:275
(Diff revision 1)
>  
>    doc.getElementById("cancel").click();
>  });
>  
> +add_task(async function onPermissionDisable() {
> +  // Enable desktop-notification permission.

You're technically not enabling notification permissions, you're setting it to the "Always Ask" state (which is the default). So you're enabling notification permission prompts? Maybe add the "prompts" here so that it's not ambiguous :)

::: browser/components/preferences/sitePermissions.css:26
(Diff revision 1)
>    margin: 1px;
>    margin-inline-end: 5px;
>  }
> +
> +#permissionsDisableText {
> +  padding: 10px 0 0 0;

Nit: Why not padding-top: 10px?

::: browser/components/preferences/sitePermissions.css:31
(Diff revision 1)
> +  padding: 10px 0 0 0;
> +  font-weight: bold;
> +}
> +
> +#permissionsDisableSubText {
> +  margin-inline-start: 36px;

It would have been nice to be able to use the .indent class, but this works for me.

::: browser/components/preferences/sitePermissions.js:65
(Diff revision 1)
> +    permissionsDisableSubText.appendChild(document.createTextNode(params.disableSubText));
> +
>      document.title = params.windowTitle;
>  
> +    // Initialize the checkbox state.
> +    let prefValue = document.getElementById("permissions.default." + this._type).value;

We should probably prepare for the case that someone adds a dialog for a permission which does not support default states and hide the checkbox if the default preference item does not exist.

::: browser/components/preferences/sitePermissions.js:286
(Diff revision 1)
>        SitePermissions.remove(uri, p.type);
>      }
> +
> +    let pref = document.getElementById("permissions.default." + this._type);
> +    if (this._checkbox.checked) {
> +      pref.value = 1;

You're doing the opposite of what you want to do. "1" is equivalent to SitePermissions.ALLOW, while you want SitePermissions.BLOCK.

To avoid this, please set the values to SitePermissions.BLOCK and SitePermissions.UNKNOWN explicitly.

::: browser/components/preferences/sitePermissions.xul:83
(Diff revision 1)
>      </hbox>
>      <spacer flex="1"/>
> +    <vbox align="start">
> +      <hbox align="start">
> +        <checkbox id="permissionsDisableCheckbox"/>
> +        <description id="permissionsDisableText"/>

This should probably be a <label for="permissionsDisableCheckbox" ..>

::: browser/locales/en-US/chrome/browser/preferences/preferences.properties:33
(Diff revision 1)
>  addons_permissions_title2=Allowed Websites - Add-ons Installation
>  popuppermissionstext=You can specify which websites are allowed to open pop-up windows. Type the exact address of the site you want to allow and then click Allow.
>  popuppermissionstitle2=Allowed Websites - Pop-ups
> -notificationspermissionstext5=The following websites have requested to send you notifications. You can specify which websites are allowed to send you notifications.
> +notificationspermissionstext6=The following websites have requested to send you notifications. You can specify which websites are allowed to send you notifications. You can also block new requests asking to allow notifications.
>  notificationspermissionstitle2=Settings - Notification Permissions
> -locationpermissionstext=The following websites have requested to access your location. You can specify which websites are allowed to access your location.
> +notificationspermissionsdisabletext=Block new requests asking to allow notifications

Nit: maybe change this name to notificationspermissionsdisablelabel (and the others, too)?

::: browser/locales/en-US/chrome/browser/preferences/preferences.properties:34
(Diff revision 1)
>  popuppermissionstext=You can specify which websites are allowed to open pop-up windows. Type the exact address of the site you want to allow and then click Allow.
>  popuppermissionstitle2=Allowed Websites - Pop-ups
> -notificationspermissionstext5=The following websites have requested to send you notifications. You can specify which websites are allowed to send you notifications.
> +notificationspermissionstext6=The following websites have requested to send you notifications. You can specify which websites are allowed to send you notifications. You can also block new requests asking to allow notifications.
>  notificationspermissionstitle2=Settings - Notification Permissions
> -locationpermissionstext=The following websites have requested to access your location. You can specify which websites are allowed to access your location.
> +notificationspermissionsdisabletext=Block new requests asking to allow notifications
> +notificationspermissionsdisablesubtext=This will prevent any websites not listed above from requesting permission to send notifications. Blocking notifications may break some website features.

Nit: maybe notificationspermissionsdisabledescription is a better name for this (and the other descriptions you added)?
Attachment #8938165 - Flags: review?(jhofmann) → review-
Duplicate of this bug: 1425426
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 32

a year ago
mozreview-review
Comment on attachment 8938165 [details]
Bug 1368744 - Provide a way for users to deny permission prompts by default in about:preferences.

https://reviewboard.mozilla.org/r/208878/#review215280

::: browser/components/preferences/sitePermissions.js:70
(Diff revision 3)
> +    // Initialize the checkbox state.
> +    if (document.getElementById("permissions.default." + this._type)) {
> +      this._currentDefaultPermissionsState = document.getElementById("permissions.default." + this._type).value;
> +    }
> +
> +    if (!this._currentDefaultPermissionsState) {

There's a bug here where SitePermissions.UNKNOWN (== 0) is caught by this if-conditition so that this checkbox will never be displayed unless you already tinkered with the default permission pref.

::: browser/components/preferences/sitePermissions.js:78
(Diff revision 3)
> +      permissionsDisableDescription.setAttribute("hidden", true);
> +    } else if (this._currentDefaultPermissionsState == SitePermissions.BLOCK) {
> +      this._checkbox.checked = true;
> +    } else {
> +      this._checkbox.checked = false;
> +    }

I don't think this whole logic is really needed. You can set the "preference" attribute on the checkbox and that should in theory make it mirror the pref you're referencing, see https://searchfox.org/mozilla-central/rev/25ff55f8209d77457af99a14269c40e2f54c1fee/browser/components/preferences/in-content/privacy.xul#434

I'm not sure whether you can set the preference attribute dynamically, can you give it a try?

::: browser/components/preferences/sitePermissions.js:297
(Diff revision 3)
> +    let pref = document.getElementById("permissions.default." + this._type);
> +    if (this._checkbox.checked) {
> +      pref.value = SitePermissions.BLOCK;
> +    } else if (this._currentDefaultPermissionsState == SitePermissions.BLOCK) {
> +      pref.value = SitePermissions.UNKNOWN;
> +    }

Again, you might be able to avoid this with the "preference" attribute.
Attachment #8938165 - Flags: review?(jhofmann) → review-
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)

Comment 35

a year ago
mozreview-review
Comment on attachment 8938165 [details]
Bug 1368744 - Provide a way for users to deny permission prompts by default in about:preferences.

https://reviewboard.mozilla.org/r/208878/#review215946

Thank you!

::: browser/components/preferences/sitePermissions.js:31
(Diff revision 6)
>    _bundle: null,
>    _removeButton: null,
>    _removeAllButton: null,
>    _searchBox: null,
> +  _checkbox: null,
> +  _currentDefaultPermissionsState: "",

Nit: The permission states are integers, so this probably shouldn't initialize to a string, maybe just null?.

::: browser/components/preferences/sitePermissions.js:66
(Diff revision 6)
> +    permissionsDisableDescription.appendChild(document.createTextNode(params.disablePermissionsDescription));
> +
>      document.title = params.windowTitle;
>  
> +    // Initialize the checkbox state.
> +    let pref = Services.prefs.getPrefType("permissions.default." + this._type);

Nit: You could save "permissions.default." + this._type as an attribute on gSitePermissionsManager.

::: browser/components/preferences/sitePermissions.xul:40
(Diff revision 6)
> +                name="permissions.default.desktop-notification"
> +                type="int" />
> +    <preference id="permissions.default.microphone"
> +                name="permissions.default.microphone"
> +                type="int" />
> +  </preferences>

Do we need this anymore?
Attachment #8938165 - Flags: review?(jhofmann) → review+
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Keywords: checkin-needed

Comment 38

a year ago
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/25d72de83498
Provide a way for users to deny permission prompts by default in about:preferences. r=johannh
Keywords: checkin-needed

Comment 39

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/25d72de83498
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox59: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Depends on: 1428425
I have reproduced this bug with Nightly 55.0a1 (2017-05-30) on Ubuntu 16.04, 64 bit!

The fix is now verified on Latest Nightly .

Build ID 	20180106100308
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
QA Whiteboard: [bugday-20180103]
I have reproduced this bug with Nightly 55.0a1 (2017-05-30) on Windows 10, 64 bit!

The bug's fix is verified with latest Nightly!

Build ID 	20180106100308
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

[bugday-20180103]
As per Comment 40 and Comment 41, I am marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
status-firefox59: fixed → verified

Updated

a year ago
Depends on: 1428581
It's too late for 58, mark 58 won't fix.
status-firefox58: affected → wontfix
Johann, will this new feature be mentioned in our release notes?
Flags: needinfo?(jhofmann)
(In reply to Pascal Chevrel:pascalc from comment #44)
> Johann, will this new feature be mentioned in our release notes?

Ah, right, thanks for the reminder, I'll make a release note request.
Flags: needinfo?(jhofmann)
Release Note Request (optional, but appreciated)
[Why is this notable]: Users can now stop intrusive websites from asking them to send notifications or access advanced device features such as camera and geolocation, while still allowing websites they trust to use these features.
[Affects Firefox for Android]: No
[Suggested wording]: Added new settings in about:preferences that allow you to stop intrusive websites from asking you [...see above]
[Links (documentation, blog post, etc)]: We're currently writing a short blog post, but it's not there yet.
relnote-firefox: --- → ?
Added to the Nightly release notes with this wording:
Added new settings in about:preferences that allow you to stop intrusive websites from asking you to receive notifications or access advanced device features such as camera and geolocation, while still allowing websites you trust to use these features.

This wording might change for the beta/release channels. We will add a link to your blog post once published. Thanks.

Comment 48

a year ago
Build ID: 20180109234707
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

Verified as fixed on Firefox Nightly 59.0a1 on Windows 10 x 64, Mac OS X 10.12 and Ubuntu 16.04 x64.

Here is the etherpad with the spot check for deny permission prompts by default: https://public.etherpad-mozilla.org/p/Deny_Permission_Prompts_By_Default
Thank you Hani!
This is in 59.0b1 notes now with the wording from comment 47.
relnote-firefox: ? → 59+

Updated

a year ago
Duplicate of this bug: 1430497
Duplicate of this bug: 1429769

Comment 53

a year ago
It's great that this capability is now in Firefox, because notification requests were getting very annoying.

Small issue: I no longer see *any* indication that a site has special capabilities I can take advantage of. There's no icon in the URL bar or indicators of any kind anywhere else --- not even anything in the Permissions dialog, which is where I now would have to go to enable notifications. 

The reason notification requests were getting annoying was because they were too in-your-face. Firefox *required* you to deal with the request, before you could get on with your browsing in peace. Now they're completely invisible! It would be good to have something in-between: i.e. just simple URL bar icons indicating special permissions requests on the current page, without the semi-blocking request prompts.

I really appreciate this capability getting in; however, a little extra help for the user would make this a truly empowering user experience.

(Digression: The permission dialog takes 4 guess-work clicks to get to: 1) Click the little (i) or lock next to the URL, 2) Don't click "Permissions" but instead click the rightward arrow next to the site certificate, 3) Click "More Information", 4) Click the "Permissions tab". The only obvious step is the last one. Actually enabling a permission involves more messing around --- permissions aren't sorted in any way that I can see --- and is probably only for the brave because it's not clear what the consequences will be. A quick-to-make and vast improvement would be to make the "Permissions" heading that appears on the site information door hanger clickable.)
(In reply to voracity from comment #53)
> It's great that this capability is now in Firefox, because notification
> requests were getting very annoying.
> 
> Small issue: I no longer see *any* indication that a site has special
> capabilities I can take advantage of. There's no icon in the URL bar or
> indicators of any kind anywhere else --- not even anything in the
> Permissions dialog, which is where I now would have to go to enable
> notifications. 
> 
> The reason notification requests were getting annoying was because they were
> too in-your-face. Firefox *required* you to deal with the request, before
> you could get on with your browsing in peace. Now they're completely
> invisible! It would be good to have something in-between: i.e. just simple
> URL bar icons indicating special permissions requests on the current page,
> without the semi-blocking request prompts.
> 
> I really appreciate this capability getting in; however, a little extra help
> for the user would make this a truly empowering user experience.
> 
> (Digression: The permission dialog takes 4 guess-work clicks to get to: 1)
> Click the little (i) or lock next to the URL, 2) Don't click "Permissions"
> but instead click the rightward arrow next to the site certificate, 3) Click
> "More Information", 4) Click the "Permissions tab". The only obvious step is
> the last one. Actually enabling a permission involves more messing around
> --- permissions aren't sorted in any way that I can see --- and is probably
> only for the brave because it's not clear what the consequences will be. A
> quick-to-make and vast improvement would be to make the "Permissions"
> heading that appears on the site information door hanger clickable.)

Please open a bug for this. We've talked about this problem before but did not consider it urgent enough to implement something immediately. We're happy to take user input on this question.
(In reply to Johann Hofmann [:johannh] from comment #54)
> Please open a bug for this.

Bug 1434597.

Updated

a year ago
Duplicate of this bug: 1435522

Comment 57

a year ago
So we're at v59 now. What is that hidden pref I need to set to shut down these constant notification requests? They're still there.
(In reply to Yves Goergen from comment #57)
> So we're at v59 now. What is that hidden pref I need to set to shut down
> these constant notification requests? They're still there.

It's not a hidden pref, it's available in: Preferences -> Privacy and Security -> Permissions

Inside the Settings for each permission there will be a checkbox to block any new requests to it.
You need to log in before you can comment on or make changes to this bug.