Closed Bug 1641713 Opened 4 years ago Closed 3 years ago

Document behaviors of browser_is_user_default histogram vs environment.settings.is_default_browser

Categories

(Firefox :: Shell Integration, task, P4)

task

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: tdsmith, Assigned: tdsmith)

Details

(Whiteboard: [dataquality])

Attachments

(1 file)

This query: https://sql.telemetry.mozilla.org/queries/71544/source

shows that several percent of main pings have a browser_is_user_default histogram recording a true value and a environment.settings.is_default_browser field indicating "false".

Can this be real? I think we expect some drift from users changing their defaults during a browser session but this seems big.

ni?jaws,dolske as people who might own one or more of these probes (hard to tell when they don't have notification_emails). Redirecting to Shell Integration for the 'default browser' mechanism chat.

Looks like the code for the histogram isn't particularly similar to the code for the environment value so I guess I wouldn't be surprised that they're different.

Note also there is a BROWSER_IS_USER_DEFAULT_ERROR histogram that might be interesting, too.

Component: Telemetry → Shell Integration
Flags: needinfo?(jaws)
Flags: needinfo?(dolske)
Product: Toolkit → Firefox

In a second run of Firefox on Windows 10, the default browser prompt appears. If you click the "Use Firefox as my default browser" button, then the BROWSER_IS_USER_DEFAULT histogram gets a 1 along with its earlier 0. Just clicking that button only brings up the "Default apps" page in the Settings app. On Win 8 or later SetDefaultBrowser() will succeed as long as it is able to launch the control panel or settings dialog, but the telemetry assumes that success means we're the default now.

This accounts for about 9% of the mismatch, looking at either BROWSER_SET_DEFAULT_ERROR = 0, or BROWSER_IS_USER_DEFAULT both 0 and 1.


In the more common case, the histogram is recorded in willCheckDefaultBrowser() (every startup even if the check isn't enabled). The difference is in the forAllTypes argument, it's false in willCheckDefaultBrowser() but true in the environment cache (second argument to ShellService.isDefaultBrowser and the first to nsIShellService::isDefaultBrowser). On Windows with forAllTypes = false we have to be the default for the http protocol, and with forAllTypes = true we also have to be associated with .html files. It doesn't seem to be used on Gnome or Mac.

I think the difference dates back to bug 791019, there's some discussion of the reasoning there back when Windows 8 was making it impossible to set defaults programmatically, basically aiming for parity with IE10.

I notice that this is roughly evenly divided between Win 10 and Win 8.1 (6.3), which is kind of suspicious given that there are so many fewer clients on 8.1. Indeed on Win 8.1 the majority have this mismatch. Maybe because in the Win 10 UI the file and protocol association are most easily set together, while on Win 8 the control panel makes it easier to associate just the protocol?

Does it seem like a reasonable proportion for having something else associated with .html?

Flags: needinfo?(jaws)
Flags: needinfo?(dolske)

I think it's safe to say these measure two different (and interestingly-different) things, so this probably doesn't indicate a fix needed. I'm happy to discuss if anyone thinks otherwise.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Thank you very much for the investigation.

It sounds like the documentation for each of these should be updated to reflect what they measure (i.e. "default http protocol handler" ± "on Windows, the default application for html files") to highlight the different possibilities for "default browser."

I can be responsible for that.

Aside:

If you click the "Use Firefox as my default browser" button, then the BROWSER_IS_USER_DEFAULT histogram gets a 1 along with its earlier 0.

Does that seem like a desirable behavior? Sending the user to the default apps page seems like something we should want to measure specifically but I don't have a use case for it today.

Assignee: nobody → tdsmith
Severity: -- → N/A
Status: RESOLVED → REOPENED
Type: defect → task
Priority: -- → P3
Resolution: INVALID → ---
Summary: browser_is_user_default histogram often disagrees with environment.settings.is_default_browser → Document behaviors of browser_is_user_default histogram vs environment.settings.is_default_browser

(In reply to Tim Smith 👨‍🔬 [:tdsmith] from comment #4)

If you click the "Use Firefox as my default browser" button, then the BROWSER_IS_USER_DEFAULT histogram gets a 1 along with its earlier 0.

Does that seem like a desirable behavior?

Probably not. It maybe made sense when a successful setAsDefault() actually meant that the default had been set (to the best of our ability), (I think this is still the case on Win 7, macOS, and Linux), but even then I don't really see the value. If you do document it, the additional count when setting the default should be included, if we don't decide to change it.

Reading back through bug 1191242 which added a lot of these probes, it looks like there was discussion of removing BROWSER_IS_USER_DEFAULT altogether given that it was largely redundant with the environment, but that was retracted because the environment was hard to access at the time. Maybe it's time to just get rid of it?

Sending the user to the default apps page seems like something we should want to measure specifically but I don't have a use case for it today.

You should be able to count this with BROWSER_SET_DEFAULT_ERROR on Win 8+.

You should be able to count this with BROWSER_SET_DEFAULT_ERROR on Win 8+.

Clarification: This histogram counts success as well as error, so you can look at the 0 bucket. This only counts in response to accepting the default browser prompt (modal or notification bar), other methods of setting the default (command line, button in about:preferences, etc) don't get recorded.

Hey Adam, this is showing up on our data quality triage due to the [data-quality] whiteboard tag and it has priority P3. Can we move this down to P4, if no one is planning to look into / fix it soon?

Flags: needinfo?(agashlin)

I think I'm the culprit here since I volunteered to write the docs change, sorry; moving this to P4 is fine with me.

Flags: needinfo?(agashlin)
Priority: P3 → P4
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/77b633db5238
Update documentation for default browser telemetry r=agashlin DONTBUILD
Flags: needinfo?(tdsmith)
Pushed by agashlin@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8b6d920cc13a
Update documentation for default browser telemetry r=agashlin
Status: REOPENED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
Whiteboard: [data-quality] → [dataquality]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: