there's a large opportunity to direct users to Firefox when opening a PDF from their OS filesystem.

While Firefox is currently listed as a potential handler for opening PDF files from outside Firefox, it's not listed as the default handler (on Windows, Edge is). Additionally, most users don't change default applications when handling specific file-formats.

This ticket tracks all work relevant to this implementation.

After a long delay, this is at the top of my list. I'll use this ticket for tracking ideas and work for this project. Things to investigate:

1. Do we have telemetry for when Firefox is opened to view a PDF? Already running and re-opened to view a PDF?
2. Can we record the user's current PDF default in our telemetry?
3. What changes are required to our UserChoice implementation to set the PDF default?
4. Can we revert to a user's previous PDF default automatically, or is this a one-way trip?

While I'm taking notes, I can confirm that .pdf is protected by user choice: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice exists on my Windows 10 machine.

(In reply to Nick Alexander :nalexander [he/him] from comment #1)

After a long delay, this is at the top of my list. I'll use this ticket for tracking ideas and work for this project. Things to investigate:

1. Do we have telemetry for when Firefox is opened to view a PDF? Already running and re-opened to view a PDF?

AFAICT, the answer is no. Bug 1243603 sounds like it will be this bit of telemetry. (That ticket and its siblings are a little tangled; Bug 1685213 was split off to handle launch method telemetry, but that won't help us understand re-engagement with Firefox due to launching PDF files.)

2. Can we record the user's current PDF default in our telemetry?

AFAICT, we're not recording the user's current browser default in our main ping telemetry, only whether this instance of Firefox is the default browser. (We do record the user's current browser in the default browser agent telemetry, but that is -- by design -- not connected to the main ping client ID.)

Technically, there's nothing challenging about fishing the .pdf file association and keeping a mapping (or doing a reverse mapping for app packages, a la Bug 1742658) to present nice values for Telemetry. But we don't do anything like this yet.

3. What changes are required to our UserChoice implementation to set the PDF default?

AFAICT, the existing mechanism should apply, mutatis mutandis. The engineering challenges here that I can see are mundane: how do we expose this API to internal consumers, how do we handle existing users who have Firefox as their browser default but have Edgium or another handler registered as PDF handler, do we keep our historical level of caution where we do the actual setting in a helper application (see https://searchfox.org/mozilla-central/rev/9a5f36b0ddb9cb8ae556fc5b45f8ccea0f0da6f8/browser/components/shell/ShellService.jsm#137-142), etc.

4. Can we revert to a user's previous PDF default automatically, or is this a one-way trip?

It appears that we can store any existing "AppID" setting and revert to the user's previous PDF default using the same user choice mechanism with which we will set Firefox's AppID to take the PDF default.

2. Can we record the user's current PDF default in our telemetry?

AFAICT, we're not recording the user's current browser default in our main ping telemetry, only whether this instance of Firefox is the default browser. (We do record the user's current browser in the default browser agent telemetry, but that is -- by design -- not connected to the main ping client ID.)

Technically, there's nothing challenging about fishing the .pdf file association and keeping a mapping (or doing a reverse mapping for app packages, a la Bug 1742658) to present nice values for Telemetry. But we don't do anything like this yet.

Bug 1742674 tracks telemetry for default PDF handlers.

3. What changes are required to our UserChoice implementation to set the PDF default?

AFAICT, the existing mechanism should apply, mutatis mutandis. The engineering challenges here that I can see are mundane: how do we expose this API to internal consumers, how do we handle existing users who have Firefox as their browser default but have Edgium or another handler registered as PDF handler, do we keep our historical level of caution where we do the actual setting in a helper application (see https://searchfox.org/mozilla-central/rev/9a5f36b0ddb9cb8ae556fc5b45f8ccea0f0da6f8/browser/components/shell/ShellService.jsm#137-142), etc.

Rather than complicate things, Bug 1743914 does a simple thing that allows a very limited form of experimentation. It adds a single Nimbus feature that, when enabled, makes setting Firefox as the default browser also set Firefox as the default PDF handler. (This is Windows 10+ and requires the user choice Nimbus feature to be enabled.) This isn't flexible -- no way to revert to previous default PDF handler, no way to set Firefox as the default PDF handler without also setting it as the default browser -- but it should be sufficient for most experiments that focus on the user experience.

2. Can we record the user's current PDF default in our telemetry?

AFAICT, we're not recording the user's current browser default in our main ping telemetry, only whether this instance of Firefox is the default browser. (We do record the user's current browser in the default browser agent telemetry, but that is -- by design -- not connected to the main ping client ID.)

In Bug 1743914 I've also added isDefaultPDFHandler to the Telemetry Environment. That's the same level of granularity we with isDefaultBrowser in our main pings.

I've scoped all of this work to Windows, but there's no real technical obstacle to doing this on macOS that I can see. We'd weaken some of the assumptions in Bug 1243603 to only require -osint on Windows, so that we'd get information about how Firefox was launched/invoked on more platforms, and then we'd need to do the equivalent of Bug 1743914 for macOS, which I think is just invoking LSSetDefaultRoleHandlerForContentType(kUTTypePDF, ...).

jimt: are we interested in macOS? As follow-up?

Not at this time. The default PDF handler on Mac is not the browser, and we will need to investigate whether Mac users expect or want that behavior similar to Windows.

(In reply to Nick Alexander :nalexander [he/him] from comment #5)

jimt: are we interested in macOS? As follow-up?

Bugs blocking the meta bug 787674 might be interesting for this work.

Does this have to be confidential or can we open it up?

(In reply to Marco Castelluccio [:marco] from comment #8)

Does this have to be confidential or can we open it up?

No real idea. I'll defer to Romain.

(In reply to Nick Alexander :nalexander [he/him] from comment #9)

(In reply to Marco Castelluccio [:marco] from comment #8)

Does this have to be confidential or can we open it up?

No real idea. I'll defer to Romain.

I don't see a reason for the bug to remain private no, happy to make it public