1385316 - Include remoteType for content processes on hangs

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Nika Layzell [:nika] (ni? for response)]

In the new ping format being added in bug 1380081, we don't currently include the remoteType of a tab process.

We should include this information (see bug 1380081 comment 44)

Comment 1

[Nika Layzell [:nika] (ni? for response)]

Attachment: Include remoteType in BHR ping

Comment 2

[Nathan Froyd [:froydnj]]

Comment on attachment 8901894 [details] [diff] [review]
Include remoteType in BHR ping

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

You need data review on sending this information.

r=me, but let's see if we can be more specific about the remoteType in the documentation, below.

::: toolkit/components/backgroundhangmonitor/HangDetails.cpp
@@ +203,5 @@
>      switch (XRE_GetProcessType()) {
>      case GeckoProcessType_Content: {
>        auto cc = dom::ContentChild::GetSingleton();
>        if (cc) {
> +        hangDetails->mDetails.mRemoteType.Assign(cc->GetRemoteType());

So annoying that this is not a CString.

::: toolkit/components/telemetry/docs/data/backgroundhangmonitor-ping.rst
@@ +33,5 @@
>              "thread": <string>, // name of the hanging thread.
>              "runnableName": <string>, // name of the runnable executing during the hang.
>                                        // Runnable names are only collected for the XPCOM main thread.
>              "process": <string>, // Type of process that hung, see below for a list of types.
> +            "remoteType": <string>, // Remote type of process which hung, if tab process.

We have a complete list of process types for the "process" field, do we have a complete list of remote types for the "remoteType" field?

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Comment on attachment 8901894 [details] [diff] [review]
Include remoteType in BHR ping

-- Request For Data Collection --
1) What are the motivating questions you want to answer with this data?
We would like to know what types of processes hang and why they hang.

2) Why does Mozilla need answers to this question? Are there benefits for users? Do we need this information to address business requirements?
This may help us improve input responsiveness metrics, and fleshes out the information we're already collecting.

3)  List all proposed measurements
High-level Description         | Measurement Type | Tracking Bug #
==========================================================
remote type of hanging process | Technical Data   | 1385316

4) How long will this data be collected?
This information will become part of the default bhr ping, which currently has no known end date, and is part of the BHR project. I am the contact for this ping.

5) What populations do you need to do these measurements for?
We're collecting this information from all users on the nightly channel. We currently have no plans to expand BHR data collection out of the nightly channel.

6) Please provide a general description of how you will analyze this data.
This information will be exposed in some way on hangs, potentially as a filterable property in the hangs.html interface.

7) What alternative methods did you consider to answer this question? Why were they not sufficient?
We're actively performing profiles of local copies of Firefox, but this has not proved sufficient to improve input latency metrics. BHR is a project to try to collect more actionable data about the hangs which occur while running Firefox.

8) Can current instrumentation answer this question?
No.

9) Where do you intend to share the results of your analysis?
http://squarewave.github.io/

Comment 4

[Nika Layzell [:nika] (ni? for response)]

Attachment: Include remoteType in BHR ping

Comment 5

[[e-mail]]

Comment on attachment 8902292 [details] [diff] [review]
Include remoteType in BHR ping

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

1) Is there documentation that describes the schema for the ultimate data set available publicly, complete and accurate?
Yes, this will be in the data docs for the ping.

2) 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)   
Yes, this appears to use a custom ping, which would suggest that it follows the opt-out mechanism in privacy preferences.

3) If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, :mystor

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

5) Is the data collection default-on or default-off? 
Default on in nightly, not in release.

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

7) Is the data collection covered by the existing Firefox privacy notice? 
Yes

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

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c3d8dd7cc191
Include remoteType in BHR ping, r=froydnj

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/c3d8dd7cc191