1694959 - Update copy for permission panel: DOM Notifications

Status: RESOLVED FIXED

(Firefox :: Site Permissions, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

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

Comment 1

[Mike Conley (:mconley) (:⚙️)]

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 2

[Mike Conley (:mconley) (:⚙️)]

ni?ing for comment 1

Comment 3

[Francesco Lodolo [:flod]]

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:

1. 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.
2. 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.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Thanks, flod. Okay, given our timelines, let's punt on porting to Fluent for the permission notifications for this iteration.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Setting to P5 until copy shows up.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

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 to Allow
• webNotifications.never should be changed to Always Block

We also need to add a new string for private browsing windows for the block action. That string should be Block.

Comment 7

[Johann Hofmann [:johannh]]

(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 to Allow
• webNotifications.never should be changed to Always 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

[Betsy Mikel [:betsymi]]

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

[Tyler Duzan]

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.

Comment 10

[:prathiksha]

Attachment: Bug 1694959 - Update copy for notifications permission panel.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/718c5be541b9
Update copy for notifications permission panel. r=mconley,flod

Comment 12

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/718c5be541b9