To start with, the event should consist of:

• category: "slow_script_warning"
• method: "shown"
• object: either "content" or "chrome" to indicate which process this happened in
• value/extra : indicate how long the script ran, how long the warning was up, and why/how the warning was dismissed (tab/browser closed, interaction with the warning, automatically when things started behaving better), if uri for hung script is chrome/resource or content-based

There are other things we want, like:

• whether there was user interaction with the content process while it was hung;
• our best guesses as to causes of the hang (system is slow, website is doing bad things, browser code being silly, ...)
• whether the tabs on which the warning was displayed were selected while things were hung (ie how often does this happen in the background)
• whether user interaction started the thing that was slow

but I think we should file follow-ups for those once we have a basic implementation. AIUI the event telemetry supports the extra event being updated with additional keys after the initial implementation, and I wouldn't want to block getting any additional info here on getting all this additional info.

Comment on attachment 9164294 [details]
Bug 1652613 - record a telemetry event when we show the slow script notification warning, r?mconley

1. What questions will you answer with this data?

How many web content hangs users are seeing, what causes them, how they respond, and how long those hangs last.

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:

We want to improve our handling of hangs based on how they affect users.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?

There aren't really alternatives to measuring this in-product if we want representative data.

4. Can current instrumentation answer these questions?

No, it accumulates hang times in a histogram, but doesn't indicate how common these were or how users and Firefox dealt with them.

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories found on the Mozilla wiki.

Tracking bug for all of these is this bug.

This collection is documented in its definitions files Histograms.json, Scalars.yaml, and/or Events.yaml and in the Probe Dictionary at https://probes.telemetry.mozilla.org.

6. How long will this data be collected? Choose one of the following:

I want this data to be collected for 6 months initially (potentially renewable).

7. What populations / release channels / countries / locales will you measure?

All of them.

8. Any other filters? Please describe in detail below.

The collection is only run on desktop (not mobile).

9. If this data collection is default on, what is the opt-out mechanism for users?

Usual telemetry opt-out measures.

10. Please provide a general description of how you will analyze this data.

Likely to be custom analysis of event pings.

11. Where do you intend to share the results of your analysis?

Unsure right now, likely to be in this bug or other reports, potentially publicly if we find something significant enough to warrant publishing more general data about what users do in the face of delays/slowness.

12 Is there a third-party tool (i.e. not Telemetry) that you are proposing to use for this data collection?

No.

Depends on D83922

Data Review Requests should be attached to the bug to integrate more seamlessly with the process. Lemme just do that here.

The hang duration numbers were bogus. It seems that the code in
XPCJSContext::InterruptCallback establishes the duration by continuously
comparing 'now' with the last timestamp in mSlowScriptCheckpoint - but it
stops writing to the latter after the second time the interrupt callback
fires. So if the slow script runtime limit is N, the timer fires every N/2
seconds, but we increment the duration by N the third time it fires, 1.5N the
fourth time, 2N the fifth time, etc.

This patch fixes the issue by always resetting the timestamp against which we
compare when establishing the duration and incrementing mSlowScriptActualWait.

Backed out 4 changesets (bug 1652613) for Browser-chrome failures in browser/browser_ProcessHangNotifications.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310897972&repo=autoland&lineNumber=14497

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedTaskRun=bh6KLzdpR16c2AHCt6AIGw.0&revision=76b5a5d243d16d4cd0ba9b640fdd4ae9d5f8555b

Backout:
https://hg.mozilla.org/integration/autoland/rev/7f26efea615b4bc6ee548842e7b4ce8bc1c615c5

https://hg.mozilla.org/mozilla-central/rev/77c85c1ef3f0
https://hg.mozilla.org/mozilla-central/rev/6e90fed2ff8a
https://hg.mozilla.org/mozilla-central/rev/5bbd29a7db14
https://hg.mozilla.org/mozilla-central/rev/74d2da543877