1932393 - Introduce a common notification ID between NotificationDB and Alerts backends

Status: NEW

(Core :: DOM: Notifications, task)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Currently we have three different ID for each notification:

• Alert name: Generated by ComputeAlertName. This is the one used to have an alert map within alerts backends. It's deterministic but not unique enough to cover different profiles.
• Notification::mID: This is the ID for notification DB. It's just UUID, it's unique but not deterministic at all.
• Windows Tag: Generated by InitWindowsTag. Windows backend specific, deterministic and unique.

Given ComputeAlertName is now called in the parent process, we should be able to port InitWindowsTag for all backends.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

Note for me:

Currently Notification generates ID, PNotification generates alertName, Windows backend generates WindowsTag. Maybe let AlertNotification generate the ID during Init() and use that for notification storage and ShowAlert(). That way chrome callers would also get the same code path for id generation.

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1932393 - Part 2: Add nsIAlertNotification.id r=nrishel,nalexander

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1932393 - Part 1: Defer calling PersistNotification until alertshow r=asuth

It's currently being called on creation instead of on show. That can cause unexpected order of persistence handling for tagged notifications, as closing previous same-tagged notification happens after the second notification creation, which means we persist the second one and then unpersist the first one. That's currently okay as each notification is being handled with UUID, but becomes a problem when we start to use deterministic notification IDs with which same tagged notifications share the same ID.