We should monitor the usage of this feature, now that we know IBM iNotes uses it.

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).

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?)

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.

OK, reporting once per session makes a lot of sense. I'll do that.

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.

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

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

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)

(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!

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

I'll write a patch to remove it per bug 1353123.