Closed
Bug 1368744
Opened 7 years ago
Closed 6 years ago
Provide a way for users to deny permission prompts by default in about:preferences
Categories
(Firefox :: Settings UI, defect)
Firefox
Settings UI
Tracking
()
VERIFIED
FIXED
Firefox 59
People
(Reporter: asa, Assigned: prathiksha)
References
Details
Attachments
(2 files)
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.
Comment 1•7 years ago
|
||
Tina, what do you think about adding a general way to disable the notification prompts entirely in about:preferences?
Flags: needinfo?(thsieh)
Comment 2•7 years ago
|
||
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 :)
Comment 4•7 years ago
|
||
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? :)
Comment 5•7 years ago
|
||
There have been discussions about Push-specific mitigations in bug 1375683.
See Also: → 1375683
Comment 6•7 years ago
|
||
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.
Comment 7•7 years ago
|
||
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)
Comment 8•7 years ago
|
||
Core:Permission Manager sounds a better fit for this issue. Do feel free to reset. :)
Updated•7 years ago
|
Component: DOM: Push Notifications → Permission Manager
Comment 10•7 years ago
|
||
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
Updated•7 years ago
|
Assignee | ||
Comment 11•7 years 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•7 years ago
|
Assignee: nobody → prathikshaprasadsuman
Status: NEW → ASSIGNED
Comment 12•7 years ago
|
||
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•7 years 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)
Comment 14•6 years ago
|
||
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)
Comment 15•6 years ago
|
||
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•6 years 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)
Comment 17•6 years ago
|
||
(In reply to mheubusch from comment #16) > block the request for new > permissions or block all [prompts, even those currently permitted. The former.
Comment 18•6 years ago
|
||
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)
Comment 19•6 years ago
|
||
(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•6 years 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)
Comment 21•6 years ago
|
||
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?
Comment 22•6 years ago
|
||
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•6 years 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!
Comment 25•6 years ago
|
||
I love the implementation mock up in comment 14. Thanks for your hard work!
Comment hidden (mozreview-request) |
Comment 27•6 years 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-
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 32•6 years 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•6 years 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•6 years ago
|
Keywords: checkin-needed
Comment 38•6 years 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•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/25d72de83498
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Comment 40•6 years ago
|
||
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]
Comment 41•6 years ago
|
||
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]
Comment 42•6 years ago
|
||
As per Comment 40 and Comment 41, I am marking this bug as verified fixed.
Status: RESOLVED → VERIFIED
Comment 43•6 years ago
|
||
It's too late for 58, mark 58 won't fix.
Comment 44•6 years ago
|
||
Johann, will this new feature be mentioned in our release notes?
Flags: needinfo?(jhofmann)
Comment 45•6 years ago
|
||
(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)
Comment 46•6 years ago
|
||
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:
--- → ?
Comment 47•6 years ago
|
||
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•6 years 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
Comment 49•6 years ago
|
||
Thank you Hani!
Comment 53•6 years 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.)
Comment 54•6 years ago
|
||
(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.
Comment 55•6 years ago
|
||
(In reply to Johann Hofmann [:johannh] from comment #54) > Please open a bug for this. Bug 1434597.
Comment 57•6 years 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.
Comment 58•6 years ago
|
||
(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.
Comment 60•5 years ago
|
||
On mobile, there doesn't seem to be an officially supported way to do this. Someone filed Bug 1451751 for it 2 years ago (no activity since over a year). Workaround seems to be to manually create the about:config setting (seems to break web notifications completely, which probably won't bother many of the users who want the prompts to go away). Workaround documented in https://bugzilla.mozilla.org/show_bug.cgi?id=1451751#c2
You need to log in
before you can comment on or make changes to this bug.
Description
•