833560 - Increase Plugin Hang UI threshold

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[(No longer employed by Mozilla) Aaron Klotz]

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

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: Threshold bump

Comment 2

[Vladan Djeric (:vladan)]

Let's check back in 10 days to see what Telemetry says about response ratios

Comment 3

[Benjamin Smedberg]

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

(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

[(No longer employed by Mozilla) Aaron Klotz]

(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

[(No longer employed by Mozilla) Aaron Klotz]

Try build for threshold bump patch:
https://tbpl.mozilla.org/?tree=Try&rev=7eb19a187ae6

Comment 7

[(No longer employed by Mozilla) Aaron Klotz]

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]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f28ed21ff0a5

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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

Comment 10

[(No longer employed by Mozilla) Aaron Klotz]

Attachment: 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]

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

[(No longer employed by Mozilla) Aaron Klotz]

Requesting Aurora checkin for attachment #710950 [details] [diff] [review] (Threshold bump), please.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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

[(No longer employed by Mozilla) Aaron Klotz]

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]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ca180542fbcd

Comment 16

[Ryan VanderMeulen [:RyanVM]]

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

Comment 17

[Manuela Muntean [Away]]

Is there a way for QA to verify the fix of this issue? Thank you!

Comment 18

[(No longer employed by Mozilla) Aaron Klotz]

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

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

[(No longer employed by Mozilla) Aaron Klotz]

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

[(No longer employed by Mozilla) Aaron Klotz]

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]]

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.