1703578 - Enable programmatic access (via UserChoice) to set Firefox as default on Windows

Status: RESOLVED FIXED

(Firefox :: Shell Integration, task, P1)

Description

[Rachel Tublitz [:rachel]]

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.

Comment 1

[Rachel Tublitz [:rachel]]

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

Comment 2

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

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.

Comment 3

[Ed Lee :Mardak]

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.

Comment 4

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

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.

Comment 5

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: WIP: Bug 1703578 - Set default browser via UserChoice.

Comment 7

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1703578 - Part 1: Generate and check UserChoice hash. r?bytesized!

Comment 8

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1703578 - Part 2: Add WDBA command to set default browser. r?bytesized!

Depends on D113426

Comment 9

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1703578 - Part 3: Invoke WDBA to set UserChoice. r?bytesized!

Depends on D113427

Comment 10

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Bug 1703578 - Part 4: Record setAsDefaultUserChoice() result telemetry. r?bytesized!

Depends on D113428

Comment 11

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: userchoice telemetry data review request

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 12

[Tim Smith (inactive) 👨‍🔬 [:tdsmith]]

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.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f91717e2d0b5
Part 1: Generate and check UserChoice hash. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/e928b3e95a6c
Part 2: Add WDBA command to set default browser. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/78617b37f199
Part 3: Invoke WDBA to set UserChoice. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/1a6d657b8e3d
Part 4: Record setAsDefaultUserChoice() result telemetry. r=bytesized

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

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

Comment 15

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Attachment: Backed out 4 changesets (Bug 1703578). r?bytesized!

Comment 16

[Ed Lee :Mardak]

This was backed out same day it landed

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

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52c06a00309e
Part 1: Generate and check UserChoice hash. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/19dce9dc4c02
Part 2: Add WDBA command to set default browser. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/91f7b8dc8670
Part 3: Invoke WDBA to set UserChoice. r=bytesized
https://hg.mozilla.org/integration/autoland/rev/fe2b9abdb53b
Part 4: Record setAsDefaultUserChoice() result telemetry. r=bytesized

Comment 18

[Marian-Vasile Laza]

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

Comment 19

[Masatoshi Kimura [:emk]]

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

Comment 20

[Pascal Chevrel:pascalc]

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

Comment 21

[Rachel Tublitz [:rachel]]

(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!

Comment 22

[Alice Wyman]

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

Comment 23

[Alex Kontos]

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

Comment 24

[Robin Steuber (she/her) [:bytesized]]

(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.

Comment 25

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(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.