1750163 - No pings are registered in about:telemetry for png/txt file types

Status: NEW

(Firefox :: Installer, defect)

Description

[Andrei Purice]

Affected Versions:
Nightly 98.0a1 (2022-01-13)
Beta 97.0b2

Affected Platforms:
Windows 10
Windows 11

Steps to reproduce:

1. Have Firefox set as the default pdf handler
2. Have a png/txt file and open it with Firefox
3. Reach about:telemetry and type "to_handle" in the search box

Expected Result:
A ping for png/txt files should be registered and can be seen under the "Key Scalars" .<other extension> .

Actual Result:
The results are blank and no ping for png/txt files are registered.

Note:
More info about this issue here : https://drive.google.com/drive/u/1/folders/1vqOyjGRNlVsXw4jpVnyvk5w9D-FpQRgf

Comment 1

[:Gijs (he/him)]

I think this is sort of expected based on the documentation for this scalar, which says:

The result is split into keys which represent the file extension: currently, the set of file types Firefox registers to handle, namely ".avif", ".htm", ".html", ".pdf", ".shtml", ".xht", ".xhtml", ".svg", ".webp", and the set of protocol schemes that Firefox registers to handle, namely "about", "http", "https", "mailto". If Firefox was invoked to handle a file type or protocol it does not register to handle by default, the count is recorded as ".<other extension>" or "<other protocol>", respectively (neither of which are valid extension or protocol identifiers).

So I guess I would expect "other extension" to show up.

The reason it doesn't is that the check at https://searchfox.org/mozilla-central/rev/3de56eb5f266f523340e739ae1b53258e0a95dfe/browser/components/BrowserContentHandler.jsm#1023 requires the osint parameter, and for files associated by the user, that commandline parameter won't be present.

Nick, thoughts?

Comment 2

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

(In reply to :Gijs (he/him) from comment #1)

I think this is sort of expected based on the documentation for this scalar, which says:

The result is split into keys which represent the file extension: currently, the set of file types Firefox registers to handle, namely ".avif", ".htm", ".html", ".pdf", ".shtml", ".xht", ".xhtml", ".svg", ".webp", and the set of protocol schemes that Firefox registers to handle, namely "about", "http", "https", "mailto". If Firefox was invoked to handle a file type or protocol it does not register to handle by default, the count is recorded as ".<other extension>" or "<other protocol>", respectively (neither of which are valid extension or protocol identifiers).

So I guess I would expect "other extension" to show up.

Yes, this is what is expected.

The reason it doesn't is that the check at https://searchfox.org/mozilla-central/rev/3de56eb5f266f523340e739ae1b53258e0a95dfe/browser/components/BrowserContentHandler.jsm#1023 requires the osint parameter, and for files associated by the user, that commandline parameter won't be present.

This I don't quite follow, and may be indicative of a misunderstanding, or may be indicative of a bug. If a user associates a file type with Firefox, it will be with the FirefoxHTML ProgID, which should always include the osint parameter.

I will review the videos to see what may be happening. (In local testing I saw the remote protocol interacting with this feature in ways that I believe are correct but that can be confusing or counterintuitive.)

Comment 3

[:Gijs (he/him)]

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

(In reply to :Gijs (he/him) from comment #1)

The reason it doesn't is that the check at https://searchfox.org/mozilla-central/rev/3de56eb5f266f523340e739ae1b53258e0a95dfe/browser/components/BrowserContentHandler.jsm#1023 requires the osint parameter, and for files associated by the user, that commandline parameter won't be present.

This I don't quite follow, and may be indicative of a misunderstanding, or may be indicative of a bug. If a user associates a file type with Firefox, it will be with the FirefoxHTML ProgID, which should always include the osint parameter.

I will review the videos to see what may be happening. (In local testing I saw the remote protocol interacting with this feature in ways that I believe are correct but that can be confusing or counterintuitive.)

In both videos, Firefox is being associated via the "other application" part of the Windows app picker, and then literally picking the .exe off the disk. In this case, I don't think it'll be associated with the FirefoxHTML ProgID.