To support our efforts to get more users to set Firefox as default, we're going to be moving ahead with setting the UserChoice hash directly in the registry to try and make this a smoother UX.

This will be an effort in tandem with the UJET team.

PI request: https://jira.mozilla.com/browse/PI-1027

Here's the shape of the feature as I've currently mostly implemented, seeking feedback.

• If we'd currently show the system Settings dialog through setDefaultBrowser(), first try setting UserChoice, and only fall back to showing Settings if that fails. This will be behind a pref, off by default for now.
• New APIs on nsIWindowsShellService:
  • setDefaultBrowserUserChoice(), which will only try to use UserChoice, throwing if it failed.
  • canSetDefaultBrowserUserChoice(), which indicates whether we expect setDefaultBrowserUserChoice() to succeed, so e.g. a different prompt could be shown.
• When we attempt to set UserChoice, accumulate the result in a Telemetry Histogram (success or one of several failure modes).

setDefaultBrowserUserChoice() could be used like:

// User clicks "set default" in a UserChoice experimental condition.
try {
  // Attempt UserChoice regardless of the pref.
  setDefaultBrowserUserChoice();
} catch {
  // Fall back to the default behavior.
  setDefaultBrowser();
}

I'm considering restructuring this to do the fallback from within setDefaultBrowserUserChoice() to make this easier, but maybe it would be more useful split out explicitly like this? For example, an experiment could avoid ever showing Settings during onboarding.

setDefaultBrowser() is already blocking in a few ways: creating the helper process and launching the system settings dialog can both block for a while. This gets worse with the UserChoice method as implemented, it launches another process and waits (currently up to 2 seconds) for it to complete in order to know whether it succeeded. Given that there would be a lot of work to move all of setDefaultBrowser() to async, and it was already blocking, I don't plan to change this, though I may reduce the wait timeout to 1 second.

Having the new APIs will be useful to experiment/holdback to use the existing functionality. A lot of existing "set default browser" calls already go through a helper jsm, so probably not too much difference if it auto-fallback from the UserChoice() version.

https://searchfox.org/mozilla-central/rev/d280cc26237b62096b89317e4ed6dea8b2bdf822/browser/components/shell/ShellService.jsm#115

In terms of async behaviors, it seems like practically most callers effectively treat it as async anyway without waiting for actually getting set default. Some immediate call sites do have synchronous behavior to report back telemetry, but that seems to only capture up to handing it off to the OS. So if we want to async error say 1 second later, a helper/wrapper would be async to await but the caller of the helper likely still won't wait.

I've reworked it to make setDefaultBrowserUserChoice() async using Subprocess.jsm, it's implemented now in ShellService.jsm instead of directly on nsWindowsShellService. It still does not fall back on its own.

ShellService.setDefaultBrowser() (which is how all existing code calls setDefaultBrowser()), now overriddes nsIShellService.setDefaultBrowser(), falling back if setDefaultBrowserUserChoice() rejects. ShellService.setDefaultBrowser() is synchronous, maintaining the status quo.

Depends on D113426

Depends on D113427

Depends on D113428

It is my intention to make this bug public once we have decided to land these patches, but we're not quite at that point yet. I will ensure this isn't landed without the review being made public.

Comment on attachment 9218513 [details]
userchoice telemetry data review request

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, in the probe definition files and the Probe Dictionary.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the Firefox telemetry opt-out.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

n/a

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Cat 2, interaction data.

5. Is the data collection request for default-on or default-off?

Default-on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes.

8. Does there need to be a check-in in the future to determine whether to renew the data?

The update team is responsible for renewing as required.

9. Does the data collection use a third-party collection tool?

No.

https://hg.mozilla.org/mozilla-central/rev/f91717e2d0b5
https://hg.mozilla.org/mozilla-central/rev/e928b3e95a6c
https://hg.mozilla.org/mozilla-central/rev/78617b37f199
https://hg.mozilla.org/mozilla-central/rev/1a6d657b8e3d

This was backed out same day it landed

https://hg.mozilla.org/mozilla-central/rev/7e775ce432b599c6daf7ac379aa42f1e9b3b33ed

https://hg.mozilla.org/mozilla-central/rev/52c06a00309e
https://hg.mozilla.org/mozilla-central/rev/19dce9dc4c02
https://hg.mozilla.org/mozilla-central/rev/91f7b8dc8670
https://hg.mozilla.org/mozilla-central/rev/fe2b9abdb53b

This is even more important on Windows 11 because the Setting app no longer allows setting .htm/.html/HTTP/HTTPS associations at once.

Rachel, should that be mentioned in our beta and final 91 release notes? Thanks

(In reply to Pascal Chevrel:pascalc from comment #20)

Rachel, should that be mentioned in our beta and final 91 release notes? Thanks

No, I think we can skip this one. Thanks!

These SUMO kb articles will need updating:
https://support.mozilla.org/en-US/kb/make-firefox-your-default-browser
https://support.mozilla.org/en-US/kb/how-change-your-default-browser-windows-10

Would it be possible for this to be uplifted to ESR91?

(In reply to Alex Kontos from comment #23)

Would it be possible for this to be uplifted to ESR91?

I'm pretty sure this code is already on ESR91. Unless I am mistaken, there is nothing to uplift that isn't there already.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #24)

I'm pretty sure this code is already on ESR91. Unless I am mistaken, there is nothing to uplift that isn't there already.

Agreed. To be sure I confirmed with 91.3.0esr (win64 en-US install on Win10 via Windows Sandbox); defaults (https, http, .html, .htm) are set as expected from onboarding or about:preferences.