1913431 - Newtab topic personalization modal blocks messaging system messages

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Emily McMinn :emcminn]

Attachment: Pocket Personalization Model.png

The new topic selection modal created for newtab/pocket has the potential to block/overlap with any messaging system messages that are normally triggered by newtab (e.g. any continuous onboarding messages/experiments). The feature was previously behind browser.newtabpage.activity-stream.discoverystream.topicSelection.enabled but is now on by default in Nightly - we should chat with the newtab team to make sure we avoid conflicts between messages.

Comment 1

[Meg Viar [:mviar]]

Hi Scott, we'd like to connect with your team on bringing this message into messaging system to avoid collisions with messages that appear on new:tab and post about:welcome flow.

Comment 2

[Punam Dahiya [:pdahiya]]

Looking at the code looks like Topic selection modal is enabled by default for US and CA region in Nightly and early beta. @sdowne is that correct? Will be great if you can help clarify what all possible flows (user profile state, frequency ) that can show current Topic Selection modal on opening about:newtab Thanks!

https://searchfox.org/mozilla-central/rev/396a6123691f7ab3ffb449dcbe95304af6f9df3c/browser/app/profile/firefox.js#1851

Comment 3

[Scott [:thecount] Downe]

Yes, it's on by default in beta and nightly in US and CA.
We should probably setup a call at some point.
Three things it sounds like we should talk about in regards to this.

What we need from messaging system going forward, so we don't need to make our own.

After a few conversations I think I have a better grasp on it than I did before, and I think we have a path forward?

1. We need a fairly minimal set of JSON, we don't want or need something that's highly configurable via omc.
2. We need it to be deployable with Nimbus and long term baked into the code without Nimbus. So first an experiment, then possibly a rollout, and then shipped in code and ride the trains. I believe this is also possible?
3. The modal needs to be triggerable from both newtab opening, or from the user clicking a button on newtab, example, the topics selection modal is also triggered when a user clicks the "add/update topics" button, not just as onboarding. I dunno if this means the UI itself needs to live in newtab not OMC, and OMC sends a message for newtab to trigger the modal, or the ability to trigger an OMC message from newtab code, or other suggestions.
4. No code duplication. Maybe using reusable components or something? So both newtab and OMC can load in the modal element and display it as needed (omc on load, and newtab on user action)
5. We need to be able to anchor it to a newtab element (or have it live in newtab)

Bringing topis selection into messaging system or ensure we don't have two modals displaying at once.

Options:

1. Right now the topics modal can be turned off with Nimbus, so the easiest solution is any messaging happening right now can flip off the topics modal until we retire it or fix it. Not ideal to be clear, but is the easiest.
2. Is there some sort of signal or state newtab can read to know if a modal is already showing, and just not trigger ours until next newtab? This seems like the next easiest short term solution.
3. Move the logic into OMC. Essentially solving and doing the list of 4 things in the previous paragraph.

How the current topics selection modal decision logic works.

Essentially answering Punam's question. Honestly, it's complicated and I don't like it. I would welcome moving the complexity of display logic into OMC, would also help guard rail against this bespoke display logic. It doesn't HAVE to work exactly like this, we need to reign in this bespoke complex logic anyway, so a change here to gain some simplicity is probably worth it.

1. The bulk of this logic is here: https://searchfox.org/mozilla-central/source/browser/components/newtab/content-src/components/Base/Base.jsx#391-430
2. They max see it 3 times.
3. If they set a topic they won't see it again (unless they open it themselves).
4. If they dismiss it, they'll see it again once more in 3 (existing profiles) or 7 (new profiles) days (unless they open it themselves).
5. If the user opens it manually, it is counted as 1 of the 3 maximum views.
6. If the user ignores it, they see it again the next day.
7. If the user clicks maybe later, it displays again in 7 days for a new profile, or 3 days for an existing profile.

Comment 4

[Punam Dahiya [:pdahiya]]

Bringing topis selection into messaging system or ensure we don't have two modals displaying at once.

Options:

1. Right now the topics modal can be turned off with Nimbus, so the easiest solution is any messaging happening right now can flip off the topics modal until we retire it or fix it. Not ideal to be clear, but is the easiest.
2. Is there some sort of signal or state newtab can read to know if a modal is already showing, and just not trigger ours until next newtab? This seems like the next easiest short term solution.
3. Move the logic into OMC. Essentially solving and doing the list of 4 things in the previous paragraph.

Another option is to enhance activeNotifications targeting used by messaging system to account for personalization modal and not display messages while personalization modal is showing.

Comment 5

[Scott [:thecount] Downe]

It's not clear how I would use activeNotification, can you explain a bit more? It looks promising though.

Comment 6

[Punam Dahiya [:pdahiya]]

(In reply to Scott [:thecount] Downe from comment #5)

It's not clear how I would use activeNotification, can you explain a bit more? It looks promising though.

I was thinking fix (add an additional check for personalization modal seen) on messaging system end by using !activeNotification targeting in all our messages which can work for most of messages except messages using defaultBrowserCheck trigger on new tab visible or defaultBrowserCheck trigger during startup that can show e.g. Messaging System Spotlight before personalization modal is shown. I believe UX will be two modal showing one after another but will test and confirm.

To make it safe we should have personalization modal display logic also have a check some thing similar to activeNotifications logic with additional check for gDialogBox from AboutNewTabParent actor (same as suggested option 2 in comment #4).

Comment 7

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

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

For more information, please visit BugBot documentation.

Comment 8

[Punam Dahiya [:pdahiya]]

Setting severity to normal as it's on by default in beta and nightly in US and CA (comment #3)

Comment 9

[Punam Dahiya [:pdahiya]]

Attachment: WIP: Bug 1913431 - Check inside activeNotification targeting

Comment 10

[Punam Dahiya [:pdahiya]]

Attachment: Default Browser Prompt collision.png

Comment 11

[Punam Dahiya [:pdahiya]]

Attachment: Tail Fox Set Default Spotlight collision.png

Comment 12

[Punam Dahiya [:pdahiya]]

I was thinking fix (add an additional check for personalization modal seen) on messaging system end by using !activeNotification targeting in all our messages which can work for most of messages except messages using defaultBrowserCheck trigger on new tab visible or defaultBrowserCheck trigger during startup that can show e.g. Messaging System Spotlight before personalization modal is shown. I believe UX will be two modal showing one after another but will test and confirm.

Tested above with FOX_DOODLE_SET_DEFAULT spotlight (#comment 11). Newtab topic selection modal is visible before spotlight with defaultbrowserCheck trigger which attached patch checking for topicSelection modal last seen should help fix

To make it safe we should have personalization modal display logic also have a check some thing similar to activeNotifications logic with additional check for gDialogBox from AboutNewTabParent actor (same as suggested option 2 in comment #4).

We still need above approach inside newtab code for avoiding collision with default browser prompt (#comment 10). @thecount noticed search tips already has a check in place to avoid colliding with default browser prompt, we can do something similar from newtab.

Comment 13

[Hanna Alemu [:hanna_a]]

Attachment: Bug 1913431 - modify activeNotifications to account for newtab topic selection modal

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4915748f3ff
modify activeNotifications to account for newtab topic selection modal r=omc-reviewers,mviar,emcminn

Comment 15

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/b4915748f3ff