Last Comment Bug 833560 - Increase Plugin Hang UI threshold
: Increase Plugin Hang UI threshold
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: x86_64 Windows 7
: P1 normal with 1 vote (vote)
: mozilla21
Assigned To: Aaron Klotz [:aklotz]
: Manuela Muntean [Away]
:
Mentors:
Depends on: 805591
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-22 13:36 PST by Aaron Klotz [:aklotz]
Modified: 2013-03-18 05:23 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
+
verified
verified


Attachments
Threshold bump (1.12 KB, patch)
2013-02-06 13:42 PST, Aaron Klotz [:aklotz]
vladan.bugzilla: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
Details | Diff | Splinter Review
Part 2: Adds timings to Plugin Hang UI telemetry (6.55 KB, patch)
2013-02-11 09:55 PST, Aaron Klotz [:aklotz]
vladan.bugzilla: review+
Details | Diff | Splinter Review

Description Aaron Klotz [:aklotz] 2013-01-22 13:36:38 PST
As mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=805591#c31, telemetry is showing that the Plugin Hang UI is more often than not cancelling itself due to plugin resumption with no user response. We also have a 2:1 ratio of wait vs terminate responses.

We don't want this to annoy the user, so increase the default for dom.ipc.plugins.hangUITimeoutSecs.
Comment 1 Aaron Klotz [:aklotz] 2013-02-06 13:42:17 PST
Created attachment 710950 [details] [diff] [review]
Threshold bump
Comment 2 Vladan Djeric (:vladan) 2013-02-07 19:52:18 PST
Let's check back in 10 days to see what Telemetry says about response ratios
Comment 3 Benjamin Smedberg [:bsmedberg] 2013-02-08 10:56:02 PST
Also note that we have data from the actual hang reports about how long people waited before killing the process, and I have a script which turns those into histograms of a sort.

Does telemetry tell us how long it took Flash to *start* responding again, and/or how long people took to click the "keep waiting" button?

If we're going to keep the hang UI on for FF 20, we need to get this into aurora soon.
Comment 4 Vladan Djeric (:vladan) 2013-02-08 13:32:00 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> Does telemetry tell us how long it took Flash to *start* responding again,
> and/or how long people took to click the "keep waiting" button?

We don't have Telemetry for this. We should add it

> If we're going to keep the hang UI on for FF 20, we need to get this into
> aurora soon.

Yes, we'll have to uplift any fixes before Feb 18th. We might also have to uplift a fix for bug 839634 to reduce likelihood of annoying users :/
Comment 5 Aaron Klotz [:aklotz] 2013-02-09 12:48:08 PST
(In reply to Vladan Djeric (:vladan) from comment #4)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #3)
> > Does telemetry tell us how long it took Flash to *start* responding again,
> > and/or how long people took to click the "keep waiting" button?
> 
> We don't have Telemetry for this. We should add it
> 
> > If we're going to keep the hang UI on for FF 20, we need to get this into
> > aurora soon.
> 
> Yes, we'll have to uplift any fixes before Feb 18th. We might also have to
> uplift a fix for bug 839634 to reduce likelihood of annoying users :/

I'll add telemetry in a follow-up patch to this bug.
Comment 6 Aaron Klotz [:aklotz] 2013-02-09 12:48:48 PST
Try build for threshold bump patch:
https://tbpl.mozilla.org/?tree=Try&rev=7eb19a187ae6
Comment 7 Aaron Klotz [:aklotz] 2013-02-09 12:52:05 PST
Comment on attachment 710950 [details] [diff] [review]
Threshold bump

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 805591
User impact if declined: Users might be annoyed by Plugin Hang UI dialog appearing too frequently
Testing completed (on m-c, etc.): Tested manually on local and with try builds
Risk to taking this patch (and alternatives if risky): Minimal, simple change to default pref
String or UUID changes made by this patch: None
Comment 8 Ryan VanderMeulen [:RyanVM] 2013-02-09 14:22:05 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/f28ed21ff0a5
Comment 9 Ryan VanderMeulen [:RyanVM] 2013-02-09 17:51:38 PST
https://hg.mozilla.org/mozilla-central/rev/f28ed21ff0a5
Comment 10 Aaron Klotz [:aklotz] 2013-02-11 09:55:47 PST
Created attachment 712495 [details] [diff] [review]
Part 2: Adds timings to Plugin Hang UI telemetry

This patch adds two new histograms:
PLUGIN_HANG_UI_RESPONSE_TIME - how long the UI was showing; this is the same value as used in the flash crash dump annotation
PLUGIN_HANG_TIME - similar to above but also includes the timeout that initially triggered the Hang UI
Comment 11 Lukas Blakk [:lsblakk] use ?needinfo 2013-02-11 15:23:33 PST
Comment on attachment 710950 [details] [diff] [review]
Threshold bump

We have one week left with 20 on Aurora, go ahead with uplift and we'll be tracking this bug to make sure any regressions or backouts stay on our radar.
Comment 12 Aaron Klotz [:aklotz] 2013-02-11 15:27:08 PST
Requesting Aurora checkin for attachment #710950 [details] [diff] [review] (Threshold bump), please.
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-02-12 06:45:29 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/c3b904a0969c

Please set the status-firefox20 flag to fixed if nothing else is intended to land on this bug.
Comment 14 Aaron Klotz [:aklotz] 2013-02-12 11:27:19 PST
checkin-needed for Part 2, attachment #712495 [details] [diff] [review]. Try build:
https://tbpl.mozilla.org/?tree=Try&rev=6d70f3933d73
Comment 15 Ryan VanderMeulen [:RyanVM] 2013-02-12 12:06:05 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/ca180542fbcd
Comment 16 Ryan VanderMeulen [:RyanVM] 2013-02-12 18:31:49 PST
https://hg.mozilla.org/mozilla-central/rev/ca180542fbcd
Comment 17 Manuela Muntean [Away] 2013-03-01 04:53:28 PST
Is there a way for QA to verify the fix of this issue? Thank you!
Comment 18 Aaron Klotz [:aklotz] 2013-03-01 09:11:35 PST
(In reply to Manuela Muntean [:Manuela] [QA] from comment #17)
> Is there a way for QA to verify the fix of this issue? Thank you!

The default timeout for the Plugin Hang UI has been increased to 11 seconds, so install a fixed version, ensure that dom.ipc.plugins.hangUIMinDisplaySecs is reset to default, and trigger the Plugin Hang UI.
Comment 19 Manuela Muntean [Away] 2013-03-08 06:22:59 PST
I've tested this on a Windows 7 64-bit machine, both with the latest Nightly (build ID: 20130307030926) and Aurora (build ID: 20130307042016) builds, and after triggering the Plugin Hang UI in 2 different ways, dom.ipc.plugins.hangUIMinDisplaySecs keeps its default value (10), it doesn't change to 11.  

The pref doesn't change it's value not even after a browser restart.
Comment 20 Aaron Klotz [:aklotz] 2013-03-08 08:47:34 PST
The default value was initially 5 and was increased to 11 by this bug. The only time that pref would read as any other value would be if the pref was manually overridden. 10 was never a default value for this pref.

The purpose of triggering the hang ui is to demonstrate that it is taking dom.ipc.plugins.hangUIMinDisplaySecs to display; it does not modify preferences.
Comment 21 Aaron Klotz [:aklotz] 2013-03-17 21:16:06 PDT
Ah, I see the problem here. dom.ipc.plugins.hangUITimeoutSecs is the pref that was adjusted in this bug, not dom.ipc.plugins.hangUIMinDisplaySecs. My apologies.
Comment 22 Manuela Muntean [Away] 2013-03-18 05:23:21 PDT
I can confirm this is now verified, on a Windows 7 64-bit machine, with:

- the latest Nightly (build ID: 20130317030923)
- the latest Aurora (build ID: 20130317042012)
- the latest Beta - Firefox 20 beta 5 (build ID: 20130313170052)


The dom.ipc.plugins.hangUITimeoutSecs preference has now the value 11.

Note You need to log in before you can comment on or make changes to this bug.