1657220 - Create separate telemetry probes for printing with the new print preview UI enabled

Status: RESOLVED FIXED

(Core :: Printing: Setup, task, P1)

Description

[Sean Voisen (:svoisen)]

We will need a telemetry probe to know when users have invoked the new print preview user interface, while preserving existing telemetry to know when users have invoked the old print dialog or print preview. Is it possible we could look at pp_open_count and simply compare when the print.tab_modal.enabled is true or false?

Comment 1

[Blake Winton (:bwinton) (:☕️)]

I don't think that's the right probe to use because we're shifting all the printing so that it invokes the preview, when previously it didn't. For instance, according to https://sql.telemetry.mozilla.org/dashboard/print-dashboard we can see pp_open_count is way lower than dialog_without_pp_open_count (MacOS: 368 vs. 728,041; Linus:31,910 vs. 271,700; Windows: 3M vs. 39M), but those numbers should be about the same in the new design…

Comment 2

[Jonathan Watt [:jwatt]]

(In reply to Sean Voisen (:svoisen) from comment #0)

Is it possible we could look at pp_open_count and simply compare when the print.tab_modal.enabled is true or false?

Martin, I think you were looking into that. Did you figure it out?

Comment 3

[Jonathan Watt [:jwatt]]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #1)

I don't think that's the right probe to use because we're shifting all the printing so that it invokes the preview, when previously it didn't. For instance, according to https://sql.telemetry.mozilla.org/dashboard/print-dashboard we can see pp_open_count is way lower than dialog_without_pp_open_count (MacOS: 368 vs. 728,041; Linus:31,910 vs. 271,700; Windows: 3M vs. 39M), but those numbers should be about the same in the new design…

As things stand with the current code, dialog_without_pp_open_count should go to zero once all printing is via the new, print preview based UI (and pp_open_count will basically go to 100%). dialog_via_pp_open_count would count the number of times someone clicked "Print using the system dialog...". Finally, silent_print_count would include the number of times users click the "Print" button in the new UI.

If anything, regardless of whether we can split the telemetry already based on the value of a pref, we probably want to separate out silent_print_count to distinguish between "silent" prints (prints not involving the system dialog) coming from the new UI and those coming from extensions. We should also call that something other than "silent" too, since user interaction was needed to send the print to the printer.

Comment 4

[Martin Balfanz [:mbalfanz]]

I thought we can check if specific prefs are set because there are some fields in telemetry that sound relevant. However, after running a few examples, I think that only specific prefs are actually tracked.

So, I think we need to either add new telemetry or start tracking the value if print.tab_modal.enabled as well.

Comment 5

[Jonathan Watt [:jwatt]]

Attachment: Bug 1657220 p1. Make print.tab_modal.enabled a static pref. r=bobowen

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: Bug 1657220. Add telemetry for new print UI. r=bobowen,mbalfanz

Depends on D87302

Comment 7

[Jonathan Watt [:jwatt]]

Attachment: Data review

Comment 8

[Chris H-C :chutten]

Comment on attachment 9170455 [details]
Data review

The review request here contains information that would excellently fill Q5 on the review request. I'm sorry I didn't make it clear in our conversation that the full form should be used, but it should.

Comment 9

[Jonathan Watt [:jwatt]]

Attachment: Data review

Comment 10

[Chris H-C :chutten]

Comment on attachment 9173445 [details]
Data review

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

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

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

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

Yes, :jwatt is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

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

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

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

Yes.

Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

---

Result: datareview+

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/47e9fdf7e93e
Add telemetry for new print UI. r=bobowen,mbalfanz

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/47e9fdf7e93e

Comment 13

[Jonathan Watt [:jwatt]]

Comment on attachment 9170427 [details]
Bug 1657220. Add telemetry for new print UI. r=bobowen,mbalfanz

Beta/Release Uplift Approval Request

• User impact if declined: No data on print overhaul reach and use.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String changes made/needed:

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9170427 [details]
Bug 1657220. Add telemetry for new print UI. r=bobowen,mbalfanz

Approved for 81.0b6.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/8a590cdc63f2