1901797 - Make !activeNotifications the default in Messaging System

Status: NEW

(Firefox :: Messaging System, defect, P1)

Description

[Ray Fambro]

Attachment: image (27).png

Comment 1

[Ray Fambro]

Attachment: Screenshot 2024-06-11 160846.png

Comment 2

[Ray Fambro]

We've recently observed a few instances where in-product messages are clashing/overlapping (see attached screenshots). This results in a major user experience concern.

We think that most of these scenarios could be resolved if we make !activeNotifications the default in Messaging System. This deserves further discussion as there might be some nuances to this that haven't yet been fully considered (eg might want to allow background notifications at the same time as about:welcome for (eg) set to default).

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

I think (but haven't verified) that three of the four messages in the examples are not FxMS messages, which is part of the problem.

We think that most of these scenarios could be resolved

Yes, but mostly (only?) for messages that are part of the messaging system, so we need to make sure that as we talk about this, we're setting expectations correctly.

A big part of this enhancement is that once we do this, if you decide to build your new message in FxMS, by default, it won't conflict with any other message in FxMS. This accelerates compounding FxMS user value by getting more new messages built into the system from the start.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mviar, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Shane Hughes [:aminomancer]]

How do we make it so that, if you forget to specify !activeNotifications in your message, and there is an active notification, the message will not show? If my targeting is just source == 'newtab', and FxMS treats that expression as if it includes && !activeNotifications, then how do I make a message do the opposite, i.e. make it allow collisions? We could make it so FxMS leaves the expression alone if it already contains the string activeNotifications. But I can't add the opposite (activeNotifications) to my targeting expression, since that doesn't mean "ignore active notifications", it means "only show if there are active notifications." I could put activeNotifications || !activeNotifications in the targeting to deal with that issue, but that's really awkward and a likely footgun.

This is fundamentally a difficult thing to handle in targeting, because a targeting expression is a series of conditions for when not to show the message, not for when to show the message.

If instead of targeting this was just a new property like this:

allow_collisions?: boolean

Then you'd be able to specify true to override the default behavior, or just leave it undefined to disallow collisions. And of course you'd need to add some code in ASRouterTargeting to check message.allow_collisions || !this.activeNotifications. This is no harder than any other approach to implementation we could take, no more lines of code at least and cuts past all the confusion from the first paragraph.

The main problem I can see is that we'd effectively be changing EVERY message that already exists. The only way to know this won't break something is to consider everything. The work here isn't so much writing code, but checking at least every type of message to see if it's supposed to be able to show while the urlbar or an infobar is showing. For the bigger ones, it's obvious. But what about ToastNotification? Moments Pages? Private Browsing Newtab? I think this could also be problematic for non-doorhanger CFRs. Probably others I'm not thinking of. Thankfully it won't create future work for us, since we'll see during development that a message isn't showing when we think it's supposed to, and we'll catch that we need to add allow_collisions to that message (or specify a rule for specific templates).