Identify default PDF handlers in Windows default browser agent/WDBA telemetry
Categories
(Firefox :: Installer, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | fixed |
People
(Reporter: nalexander, Assigned: nrishel)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidedi-ope])
Attachments
(4 files)
On Windows, Microsoft Edge (Edgium) is the default browser and the default PDF handler. Setting Firefox as the default browser does not set it as the default PDF handler, which will leave some Firefox users with a mixed environment.
Mozilla has invested heavily into improving Firefox's PDF handling and we'd like to set Firefox as the default PDF handler. But, we want to be respectful of folks who are choosing a third-party PDF handler (such as Adobe Acrobat). Collecting telemetry about what PDF handlers are common will help us register as the default PDF handler in a respectful manner.
We could collect such telemetry in main pings or in WDBA telemetry. The former is associated to a telemetry client ID; the latter is -- by design -- not associated to a telemetry client ID.
Reporter | ||
Comment 1•3 years ago
|
||
jimt: for the experiments you plan around default PDF handling, are aggregate statistics about PDF handlers Firefox users have set as default sufficient? Or do we need to be able to associate specific users with specific PDF handlers (perhaps grouped or filtered in some way)?
Reporter | ||
Comment 2•3 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #1)
jimt: for the experiments you plan around default PDF handling, are aggregate statistics about PDF handlers Firefox users have set as default sufficient? Or do we need to be able to associate specific users with specific PDF handlers (perhaps grouped or filtered in some way)?
romain: same question. I'm not really sure who in the product organization is most interested in this data right now.
Do you (or other folks in product) have any notion of what the top N (say, 5 or 10) most popular PDF viewers are going to be on Windows? I've done a little searching and it seems there are many, many options, but who knows what market share really looks like. Since nothing in the WDBA is associated to a single user, I wonder if we might collect all of the PDF handlers we see to determine popular PDF viewers, either for some channels (i.e., up to beta) or for a limited amount of time: we collect a list and then filter to the popular ones. Thoughts?
Comment 3•3 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #2)
(In reply to Nick Alexander :nalexander [he/him] from comment #1)
jimt: for the experiments you plan around default PDF handling, are aggregate statistics about PDF handlers Firefox users have set as default sufficient? Or do we need to be able to associate specific users with specific PDF handlers (perhaps grouped or filtered in some way)?
romain: same question. I'm not really sure who in the product organization is most interested in this data right now.
Do you (or other folks in product) have any notion of what the top N (say, 5 or 10) most popular PDF viewers are going to be on Windows? I've done a little searching and it seems there are many, many options, but who knows what market share really looks like. Since nothing in the WDBA is associated to a single user, I wonder if we might collect all of the PDF handlers we see to determine popular PDF viewers, either for some channels (i.e., up to beta) or for a limited amount of time: we collect a list and then filter to the popular ones. Thoughts?
I think collecting on release for a limited amount of time would work best given how unrepresentative Beta is geo-wise (mostly India and Indonesia) - I'd expect different softwares in different countries.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
Depends on D136814
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
P1 - actively in review, N/A severity - no impact on users.
Assignee | ||
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Sorry for the delay in reviewing! Looking now
Comment 10•3 years ago
|
||
Comment on attachment 9261973 [details]
raw_pdf_telemetry_data_collection_review_request_v1.md
Note this is category 1, not category 2, data.
data-review-+
- Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way? Click the documentation link provided in Q6 and ensure it is publicly accessible and does or will contain documentation for the data collection. (see here, here, and here for examples). Refer to the appendix for "documentation" if more detail about documentation standards is needed.
Yes, existing telemetry documentation.
- Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.
Yes, existing telemetry opt-out.
- If the request is for permanent data collection, is there someone who will monitor the data over time?
N/A, this is a temporary collection
- Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1 - the default PDF application name falls under machine info
- Is the data collection request for default-on or default-off?
default-on
- 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
- Is the data collection covered by the existing Firefox privacy notice?
Yes
- Does the data collection use a third-party collection tool?
No
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Backed out 3 changesets (bug 1742674) for causing build bustages in mozapps/defaultagent/Registry.
Backout link: https://hg.mozilla.org/integration/autoland/rev/2500c3309c3f68accd88c0f4548eed584536e77f
INFO - lld-link: error: undefined symbol: class mozilla::Result<class std::basic_string<wchar_t, struct std::char_traits<wchar_t>, class std::allocator<wchar_t>>, class mozilla::WindowsError> __cdecl Utf8ToUtf16(char const *const)
[task 2022-02-15T22:05:46.970Z] 22:05:46 INFO - >>> referenced by /builds/worker/checkouts/gecko/toolkit/mozapps/defaultagent/Registry.cpp:113
[task 2022-02-15T22:05:46.970Z] 22:05:46 INFO - >>> ../../mozapps/defaultagent/tests/gtest/Unified_cpp_tests_gtest0.obj:(class mozilla::Result<struct mozilla::Ok, class mozilla::WindowsError> __cdecl RegistrySetValueString(enum IsPrefixed, wchar_t const *, char const *, wchar_t const *))
[task 2022-02-15T22:05:46.970Z] 22:05:46 INFO - lld-link: error: undefined symbol: class mozilla::Result<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>, class mozilla::WindowsError> __cdecl Utf16ToUtf8(wchar_t const *const)
[task 2022-02-15T22:05:46.971Z] 22:05:46 INFO - >>> referenced by /builds/worker/checkouts/gecko/toolkit/mozapps/defaultagent/Registry.cpp:92
[task 2022-02-15T22:05:46.971Z] 22:05:46 INFO - >>> ../../mozapps/defaultagent/tests/gtest/Unified_cpp_tests_gtest0.obj:(class mozilla::Result<class mozilla::Maybe<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>>, class mozilla::WindowsError> __cdecl RegistryGetValueString(enum IsPrefixed, wchar_t const *, wchar_t const *))
[task 2022-02-15T22:05:46.971Z] 22:05:46 ERROR - gmake[4]: *** [/builds/worker/checkouts/gecko/config/rules.mk:531: xul.dll] Error 1
Comment 13•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Comment 14•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/74cadf712a3d
https://hg.mozilla.org/mozilla-central/rev/0af2b5c33d89
https://hg.mozilla.org/mozilla-central/rev/a74a25f5da40
Description
•