Closed Bug 1694959 Opened 7 months ago Closed 7 months ago

Update copy for permission panel: DOM Notifications

Categories

(Firefox :: Site Permissions, task, P3)

task

Tracking

()

RESOLVED FIXED
88 Branch
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

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.

ni?ing for comment 1

Flags: needinfo?(francesco.lodolo)

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.

Flags: needinfo?(francesco.lodolo)

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

Severity: -- → N/A
Priority: -- → P1

Setting to P5 until copy shows up.

Priority: P1 → P5

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.

(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.

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?

Flags: needinfo?(tduzan)

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.

Flags: needinfo?(tduzan)
Priority: P5 → P3
Assignee: nobody → prathikshaprasadsuman
Status: NEW → ASSIGNED
Pushed by prathikshaprasadsuman@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/718c5be541b9
Update copy for notifications permission panel. r=mconley,flod
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
You need to log in before you can comment on or make changes to this bug.