Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

For #11961: collect telemetry on all unique unsupported features that… #11969

Conversation

emalysz
Copy link
Contributor

@emalysz emalysz commented Jun 4, 2020

… trigger fallback error.

This expands upon the telemetry we are collecting that shows the fallback error.

web/app.js Outdated
@@ -867,6 +868,15 @@ const PDFViewerApplication = {
typeof PDFJSDev === "undefined" ||
PDFJSDev.test("MOZCENTRAL || GENERIC")
) {
if (featureId && !this._unsupportedFeatureErrors.includes(featureId)) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

null check for featureId because of the changes made in #11953. That would trigger fallback() with a null featureId

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm mistaken, wouldn't it be a lot simpler/safer to do this kind of validation/tracking of seen featureIds in the new case that you're adding to ChromeActions.reportTelemetry and simply report unconditionally here instead (note how e.g. documentStats is implemented)?

Since that's the central spot where all telemetry results pass through, you'd be thus be guaranteed to only report a specific featureId value once.
By tracking seen featureIds manually in web/app.js, as is done in this patch, it seems much easier for any future changes to accidentally e.g. double-report telemetry data if one forgets to add a this._unsupportedFeatureErrors.push(featureId); line.

@timvandermeij
Copy link
Contributor

timvandermeij commented Jun 4, 2020

I think I'm missing something here, but we already have the PDF_VIEWER_FALLBACK_REASON telemetry probe here, so we should already collect the unique unsupported features? Or is the issue that we're currently only reporting the first error even if there are more?

@emalysz
Copy link
Contributor Author

emalysz commented Jun 4, 2020

Hey @timvandermeij, sorry if I wasn't clear about this. The PDF_VIEWER_FALLBACK_REASON tells us the reason the fallback bar is shown. However, forms can have multiple errors (https://www.irs.gov/pub/irs-pdf/f1040.pdf will have form, javascript, and font errors). Since only the first error is shown, we wanted to add telemetry to see the total number of errors that trigger the fallback (meaning most are not reflected in the fallback bar). This probe would allow us to record all three of those above errors, not just form.

web/app.js Outdated
@@ -1235,6 +1244,11 @@ const PDFViewerApplication = {
return false;
}
console.warn("Warning: JavaScript is not supported");
this.externalServices.reportTelemetry({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why this cannot be done (unconditionally) in the fallback method? There are more kinds of unsupported features, so why are only these special-cased here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I originally thought the same thing, but was hesitant given my work in #11953 (which I think will land before this patch). There, we would trigger the fallback for form and script errors only when the user clicks, and featureId would be null.

So once that lands, I could implement a loop to report the errors within this._delayedFallbackFeatureIds in the fallback method, or the errors could be reported in these two places when we trigger a console.warn. Which would you prefer?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I'm thinking it's easiest if we can consolidate the telemetry reporting in one place, but we can see how it looks once the other PR is merged.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm mistaken, by making these changes in the latest version of the patch it's no longer guaranteed that telemetry reporting happens for the delayed fallback cases.

Consider the case where a document only contains "forms" (and nothing else that'd trigger fallback), and where the user does not interact with the viewer (i.e. no click and/or tab). In that case, the way I'm reading the code, there will not be any PDFViewerApplication.fallback call and thus no telemetry data reported.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that out @Snuffleupagus. I opted to create a helper method to avoid reportTelemetry code duplication.

Another option I considered was calling fallback here but passing in an optional bool that would tell us to immediately exit the function following the telemetry collection.

Which solution do you each prefer? @timvandermeij

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option I considered was calling fallback here but passing in an optional bool that would tell us to immediately exit the function following the telemetry collection.

That honestly sounds worse than the current solution, as far as I'm concerned :-)

(There may be potential for some additional clean-up, since I do think that we're now tracking a bit more state than is probably desirable, but that's perhaps better for a follow-up patch.)

@timvandermeij
Copy link
Contributor

timvandermeij commented Jun 4, 2020

Since only the first error is shown, we wanted to add telemetry to see the total number of errors that trigger the fallback (meaning most are not reflected in the fallback bar).

Ah, that was the missing piece for me. Thank you for clarifying that! I was always under the impression that we reported all errors instead of only the first one.

I'm not sure if the existing probe PDF_VIEWER_FALLBACK_REASON is a bit misleading in a sense as I would expect all fallback reasons to be reflected in that, not just one of them. Shouldn't we repurpose that one instead of adding a new one, or are we then worried about skewed data?

web/app.js Outdated Show resolved Hide resolved
@emalysz emalysz force-pushed the 11961-unsupported-feature-telemetry-error branch from 5933ea7 to 6eb41c9 Compare June 8, 2020 15:36
@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

pdfjsbot commented Jun 8, 2020

From: Bot.io (Linux m4)


Received

Command cmd_preview from @timvandermeij received. Current queue size: 0

Live output at: http://54.67.70.0:8877/cd42dcd629e9bac/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Jun 8, 2020

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/cd42dcd629e9bac/output.txt

Total script time: 3.48 mins

Published

@timvandermeij
Copy link
Contributor

Looks good to me. Can we already land this or should we wait for the upstream change to be done first?

@emalysz emalysz force-pushed the 11961-unsupported-feature-telemetry-error branch 2 times, most recently from 6b41f15 to 372859b Compare June 11, 2020 17:01
@timvandermeij
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_preview from @timvandermeij received. Current queue size: 0

Live output at: http://54.67.70.0:8877/2067121fe907c7b/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/2067121fe907c7b/output.txt

Total script time: 3.43 mins

Published

web/app.js Outdated
_recordFallbackErrorTelemetry(featureId) {
if (
typeof PDFJSDev === "undefined" ||
PDFJSDev.test("MOZCENTRAL || GENERIC")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why GENERIC here as well? As far as I can see reportTelemetry is only implemented and useful in MOZCENTRAL builds.

@emalysz emalysz force-pushed the 11961-unsupported-feature-telemetry-error branch from 372859b to 9faf233 Compare June 11, 2020 22:04
…es that trigger fallback error.

This expands upon the telemetry we are collecting that shows the fallback error.
@emalysz emalysz force-pushed the 11961-unsupported-feature-telemetry-error branch from 9faf233 to 05fe9c8 Compare June 11, 2020 22:13
@timvandermeij timvandermeij merged commit d75a068 into mozilla:master Jun 12, 2020
@timvandermeij
Copy link
Contributor

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants