Closed Bug 1703578 Opened 7 months ago Closed 4 months ago

Enable programmatic access to set Firefox as default on Windows

Categories

(Firefox :: Shell Integration, task, P1)

task

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: rachel, Assigned: agashlin)

References

(Blocks 2 open bugs, )

Details

Attachments

(6 files, 1 obsolete file)

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.

Status: NEW → ASSIGNED
Priority: -- → P1

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.

Duplicate of this bug: 1686286
Attachment #9217612 - Attachment is obsolete: true

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.

Attachment #9218513 - Flags: data-review?(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.

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

Yes, the Firefox telemetry opt-out.

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

n/a

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

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

Default-on.

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

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

Yes.

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

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

No.

Attachment #9218513 - Flags: data-review?(tdsmith) → data-review+
Group: mozilla-employee-confidential
Pushed by agashlin@mozilla.com:
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
Group: mozilla-employee-confidential
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 90 Branch → ---
Group: mozilla-employee-confidential
Pushed by agashlin@mozilla.com:
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
Regressions: 1719189

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

Flags: needinfo?(rtublitz)

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

Flags: needinfo?(rtublitz)
Blocks: 1728019
No longer blocks: 1728019
See Also: → 1728019
See Also: → 1736631
You need to log in before you can comment on or make changes to this bug.