Add telemetry for remote jar channel usage

RESOLVED FIXED in Firefox 46

Status

()

Core
Networking
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

unspecified
mozilla48
Points:
---

Firefox Tracking Flags

(firefox46 fixed, firefox47 fixed, firefox48 fixed)

Details

(Whiteboard: [necko-active])

Attachments

(1 attachment)

(Assignee)

Description

2 years ago
We should monitor the usage of this feature, now that we know IBM iNotes uses it.
(Assignee)

Comment 1

2 years ago
Created attachment 8729754 [details] [diff] [review]
Start collecting telemetry data on the usage of remote JAR protocol in the wild
Attachment #8729754 - Flags: review?(mcmanus)
Comment on attachment 8729754 [details] [diff] [review]
Start collecting telemetry data on the usage of remote JAR protocol in the wild

Review of attachment 8729754 [details] [diff] [review]:
-----------------------------------------------------------------

you can land this if you want, but I'm curious how you put the resulting count into context..

I often use a static and only report something like that once per session and then we can get a fraction of sessions that use it (lots of things count once per session for comparison).
Attachment #8729754 - Flags: review?(mcmanus) → review+
Whiteboard: [necko-active]
(Assignee)

Comment 3

2 years ago
My goal was to get to a number that we can watch for to drop down to 0.

But I'm curious to know if there is anything better to measure here.  Can you give me an example of a per-session measurement you had in mind?  Does the same logic apply for things that we expect to not happen in *most* sessions (such as accessing remote JAR protocol?)
Flags: needinfo?(mcmanus)
I was thinking of something like this..

https://mxr.mozilla.org/mozilla-central/source/netwerk/base/nsAutodialWin.cpp#274

seems that you can compare the results against other things that are known to report once per session (browser_is_user_default ?) to get a fraction..

but even if a comparison against 0 is all you have, it seems interesting to filter out "N" calls per session when you don't have any feel for how big N might be.
Flags: needinfo?(mcmanus)
(Assignee)

Comment 5

2 years ago
OK, reporting once per session makes a lot of sense.  I'll do that.
(Assignee)

Comment 7

2 years ago
Comment on attachment 8729754 [details] [diff] [review]
Start collecting telemetry data on the usage of remote JAR protocol in the wild

Approval Request Comment
[Feature/regressing bug #]: Not a regression, but a telemetry probe that will help us monitor the usage of the remote JAR feature that caused us to release 45.0.1.
[User impact if declined]: I'd like to start collecting telemetry on this sooner than later, but there's no negative impact from not taking this other than a delay in collecting telemetry.
[Describe test coverage new/current, TreeHerder]: N/A
[Risks and why]: Very low risk.
[String/UUID change made/needed]: None.
Attachment #8729754 - Flags: approval-mozilla-beta?
Attachment #8729754 - Flags: approval-mozilla-aurora?

Comment 8

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/8b9681467229
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48

Updated

2 years ago
status-firefox46: --- → affected
status-firefox47: --- → affected

Comment 9

2 years ago
Comment on attachment 8729754 [details] [diff] [review]
Start collecting telemetry data on the usage of remote JAR protocol in the wild

New telemetry probe, Aurora47+, Beta46+ so we can anticipate situations similar to what prompted us to do 45.0.1
Attachment #8729754 - Flags: approval-mozilla-beta?
Attachment #8729754 - Flags: approval-mozilla-beta+
Attachment #8729754 - Flags: approval-mozilla-aurora?
Attachment #8729754 - Flags: approval-mozilla-aurora+

Comment 10

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/37642befed59
status-firefox47: affected → fixed

Comment 11

2 years ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-beta/rev/30d8a8e73dc6
status-firefox46: affected → fixed
And that trivial merge conflict I easily fixed on the beta uplift was completely wrong. Here's a followup to get it working: https://hg.mozilla.org/releases/mozilla-beta/rev/ba0ba065a4d5

Updated

a year ago
See Also: → bug 1329336
Does all of dev-platform really need to get mail about this probe? Ditto for bug 1301123.

(Also I believe new probes are required to get a data steward review nowadays)
Flags: needinfo?(ehsan)
(Assignee)

Comment 14

a year ago
(In reply to David Major [:dmajor] from comment #13)
> Does all of dev-platform really need to get mail about this probe? Ditto for
> bug 1301123.

If you know of a better mailing list, let me know!
Flags: needinfo?(ehsan)
Ehsan--do we want to update the expiration for this probe or remove it?

The following histograms will be expiring on 2017-04-17, and should be removed from the codebase, or have their expiry versions updated:

* REMOTE_JAR_PROTOCOL_USED expires in version 55.0a1
Flags: needinfo?(ehsan)
(Assignee)

Comment 16

a year ago
I'll write a patch to remove it per bug 1353123.
Flags: needinfo?(ehsan)
You need to log in before you can comment on or make changes to this bug.