1827441 - [Experiment] The "Make primary browser" prompt is wrongly displayed right after Firefox was set as the default browser through the "Set as default" doodle spotlight

Status: RESOLVED WONTFIX

(Firefox :: Messaging System, defect, P1)

Description

[Marius Coman [:mcoman], Ecosystem QA - PTO until 8th of November, for any requests ping :cmuresan]

Attachment: rec of the issue.gif

[Affected versions]:

• Firefox Release 112.0 - Build ID: 20230406114409

[Affected Platforms]:

• Windows 10 x64
• macOS 12.6.1

[Prerequisites]:

• Have the "user.js" file saved to your PC.
• Have a profile older than 28 days.
• Firefox is not set as the default browser.
• The "Always check if Firefox is your default browser" option from the "about:preferences" page is checked.

[Steps to reproduce]:

1. Open the browser with the profile from the prerequisites.
2. Navigate to the profile folder and paste the "user.js" file from prerequisites.
3. Restart the browser and click the "Not now" button from the "Make primary browser" prompt.
4. Restart the browser again.
5. Click the "Open my links with Firefox" from the "Set as default" spotlight.
6. Observe the behavior.

[Expected result]:

• The "Set as default" spotlight is dismissed and the browser is set as default.

[Actual result]:

• The "Set as default" spotlight is dismissed, however, the "Make primary browser" prompt is displayed even if the browser is already set as default.

[Notes]:

• Attached is a screen recording of the issue:

Comment 1

[Vtay]

This looks similar to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1364832

Shane - adding you to this bug since you're looking at the other one.

This is not a blocker to launch the experiment.

Comment 2

[Shane Hughes [:aminomancer]]

I don't think this is actually the same bug. I wonder if this might be related to the parameter issue I mentioned here

Comment 3

[Ed Lee :Mardak]

I thought we were trying to avoid the double back-to-back messages? Although in this case it seems like spotlight somehow showed before the prompt?

We should be able to use willShowDefaultPrompt in the targeting?

Comment 4

[Shane Hughes [:aminomancer]]

Or just source == "startup" - From the gif it looks like the reason the spotlight is showing before the prompt is because it's being triggered by the source: "newtab" defaultBrowserCheck, before the BrowserGlue._maybeShowDefaultBrowserPrompt idle task has run.

Might be sensible to do something to delay the newtab defaultBrowserCheck until after idle tasks have finished?

Comment 5

[Ed Lee :Mardak]

(In reply to Shane Hughes [:aminomancer] from comment #4)

Or just source == "startup"

It is strange that the spotlight shows before the prompt, but it could still potentially be startup as the prompt is async. https://searchfox.org/mozilla-central/rev/ad732108b073742d7324f998c085f459674a6846/browser/components/BrowserGlue.sys.mjs#5399,5401,5414,5438

It's not clear which experiment is tested but sounds like https://experimenter.services.mozilla.com/nimbus/q2-set-to-default-fox-doodle-en-holdback already has the startup source check.

Comment 6

[Shane Hughes [:aminomancer]]

Humm... yeah that's a good point. So you think the Spotlight is attempting to open immediately but it's just being delayed until the prompt is closed? That would explain why the message is still showing even though Firefox is now the default browser. Like, the targeting was evaluated while the prompt was still open, before Firefox was set to default. And it was just the actual opening of the SubDialog that was delayed until the prompt was closed.

Since it's an async prompt, I would have expected that if you try to open a dialog while the prompt is open, it would just fizzle and do nothing. I figured the "queueing" behavior of prompts was just a consequence of (synchronous) prompt 1 spinning the event loop until closed. But if I'm mistaken then that would explain the behavior...

But either way, it seems like one easy fix would be to just await DefaultBrowserCheck.prompt(win). The whole thing is happening in an idle task so I don't think that would cause any problems with startup. It may be a moot point if we end up removing these messages or converting them into ASRouter messages. That might take us a while to make a decision though

Comment 7

[Shane Hughes [:aminomancer]]

Hey Marius, do you know the experiment slug? If not, I can figure it out. Just figured I'd ask first before trying to match the experiment targeting.

Comment 8

[Marius Coman [:mcoman], Ecosystem QA - PTO until 8th of November, for any requests ping :cmuresan]

Hey, Shane! Sorry for the late answer, we were out of the office on Friday and Monday due to Easter Holidays.

This issue was found while testing the "Set to default - Fox Doodle" holdback experiments. Here are the experimenter tickets:

https://experimenter.services.mozilla.com/nimbus/q2-set-to-default-fox-doodle-en-holdback/summary
https://experimenter.services.mozilla.com/nimbus/q2-set-to-default-fox-doodle-fr-holdback/summary
https://experimenter.services.mozilla.com/nimbus/q2-set-to-default-fox-doodle-de-holdback/summary

If you need any extra information please don't hesitate to ping me.

Comment 9

[Shane Hughes [:aminomancer]]

Thanks! That seems to support Ed's theory.

This problem could be resolved in bug 1826232, as long as we don't make any local spotlight messages triggered on defaultBrowserCheck. If we put the sendTriggerMessage call first, we can skip showing the prompt if it resolved with a message. This is kinda like what FeatureCallout does. But we're having a meeting today to discuss what we want to do with the prompt in general (per bug 1825381). If we end up removing the prompt or moving it into ASRouter, which seems likely, then that will also resolve this.

Comment 10

[Shane Hughes [:aminomancer]]

After this experiment launched, we settled on a strategy to avoid this issue recurring. For the time being, we will use the willShowDefaultPrompt targeting attribute in future experiments to prevent any conflicts with the default browser prompt. And we'll try to ensure this requirement is discoverable by adding an explanation to the relevant documentation (see bug 1828745). Later, we may choose to do some feature work to allow the messaging system to override (i.e., prevent from showing) the default browser prompt. That's not critical for now, though. We just need to prevent overlap, for which purpose this targeting is sufficient.