Update copy for permission panel: DOM Notifications
Categories
(Firefox :: Site Permissions, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: mconley, Assigned: prathiksha)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-door-hangers])
Attachments
(1 file)
We're still waiting on what the exact strings are, but this bug will be updated as soon as we have them.
We'll want to convert the strings to using Fluent where practical.
The code powering DOM Notifications is here: https://searchfox.org/mozilla-central/rev/df23c6e58c6be1eb8399e475878f73d4867bef87/browser/modules/PermissionUI.jsm#939-1047
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
Hey flod, the way PopupNotifications works is that the message string passed to them can contain a "<>" or "{}" string for which certain values are interpolated: https://searchfox.org/mozilla-central/rev/df23c6e58c6be1eb8399e475878f73d4867bef87/toolkit/modules/PopupNotifications.jsm#380-387
Given how much time we have to pull this off, I can't say I'm jazzed about the idea of reworking PopupNotifications to use Fluent variables. Is it acceptable to continue to use the {}
and <>
interpolation for the resulting Fluent strings?
If not, we might want to punt on Fluent conversions for PopupNotification panels, and keep using .properties
until we get a chance to rework this stuff.
Comment 3•3 years ago
|
||
The <>
and {}
are only used internally, not exposed to localization. In the strings we have normal variables, interpolated by the code you linked to. For example:
webNotifications.receiveFromSite2=Will you allow %S to send notifications?
Internally it becomes Will you allow <> to send notifications
, before going into the actual code that splits it into parts.
Using <>
and {}
directly in the Fluent strings is not an option, we would have zero controls and checks over them. So, I see two options:
- Change the code to convert Fluent string with variables in the intermediate form. As far as I understand it, the rest of the code would remain the same.
- Keep using .properties
I'd be OK with option 2, as long as we have a bug on file and a plan to move these strings to Fluent at some point. Zibi might also have better ideas on how 1 could be solved with Fluent, and how much work that would be.
My memory might be completely off, but I think we created those helpers to allow formatting and HTML without .innerHTML, and it might not be needed at all with Fluent.
Reporter | ||
Comment 4•3 years ago
|
||
Thanks, flod. Okay, given our timelines, let's punt on porting to Fluent for the permission notifications for this iteration.
Updated•3 years ago
|
Reporter | ||
Comment 6•3 years ago
|
||
Got copy. The strings are around https://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.properties#648
webNotifications.receiveFromSite2
should be changed to:Allow %S to send notifications?
webNotifications.allow
should be changed toAllow
webNotifications.never
should be changed toAlways Block
We also need to add a new string for private browsing windows for the block action. That string should be Block
.
Comment 7•3 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos) from comment #6)
Got copy. The strings are around https://searchfox.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.properties#648
webNotifications.receiveFromSite2
should be changed to:Allow %S to send notifications?
webNotifications.allow
should be changed toAllow
webNotifications.never
should be changed toAlways Block
We also need to add a new string for private browsing windows for the block action. That string should be
Block
.
We should consider simply saying "Block" instead of "Always Block". We know that users are hesitant to make decisions that appear to have permanent consequences, and in this case it might be preferable not to suggest that too strongly.
Comment 8•3 years ago
|
||
Thanks Johann, I agree with your recommendation. Though DOM notifications work differently on the technical end than other notifications because these are more permanent than say Location or Camera, which prompt every time, by surfacing this technical complexity to users in the strings themselves, we risk confusing people more and scaring them away from selecting the 'Block' action. Tyler, will you consider Block-Allow on the DOM notifications given this discussion?
Comment 9•3 years ago
|
||
We had a discussion about this in the handoff slide deck. I think it's better to have "Always Block", because we are setting user expectations with how we describe the functionality. Every other permissions panel operates where choosing to block is a temporary action, but with notifications it is remembered. We need to surface that somehow, and the current text does this by saying "Never Allow". "Always Block" is just a text reversal of "Never Allow" that conforms to the new string designs. I'm open to an argument otherwise, but I'd need to hear something compelling, as this doesn't represent a significant change from our existing strings and clearly describes the actual technical behavior.
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
Pushed by prathikshaprasadsuman@gmail.com: https://hg.mozilla.org/integration/autoland/rev/718c5be541b9 Update copy for notifications permission panel. r=mconley,flod
Comment 12•3 years ago
|
||
bugherder |
Description
•