[Tracking Requested - why for this release]: [Tracking Requested - why for this release]: Setting dom.ipc.plugins.asyncdrawing.enabled = false fixes the problem Reproducible: 100% Steps To Reproduce: 1. Open http://ja.y8.com/games/pirate_the_treasures_return in a new tab 2. Wait for loading the game menu 3. Click [>] button --- observe, hover highlight, response 4. Click [PLAY] in "LOCAL SAVE" pane --- observe, hover highlight, response 5. Wait for loading the game 6. Press [W] ,[SPACE] key to jump --- observe, whether the hunter jumps or not 7. Click on the game area --- observe, whether the weapon is fired or not 8. When a game finished, Click on [reload] icon to restart the game --- observe, hover highlight, response Actual Results: Button would not respond. Nothing happens with Key press. Sometimes, it respond after toggle window size mode (minimize, restore) or switch tabs Expected Results: The button should highlight when hover over and click on it. The button and key should be respond.

Hmm, no issues here with nightly and async painting turned on. Tracy, please test this game in a slower vm to see if you can reproduce.

With latest Nightly, I can repro slow response to clicks when in asyncdrawing mode. Is not reproducible with asycdrawing turned off. It is more easily reproduced while several other tabs were open with flash animations. in this case, I had Alice's test case from bug 1314467 opened in 5 other tabs.

Track 51+/52+ as regression related to flash.

Hi :jimm, Can you help find an owner for this per comment #2?

FYI, disabling Flash Plugin Protect Mode fixes the problem. https://hg.mozilla.org/mozilla-central/rev/79feeed4293336089590320a9f30a813fade8e3c Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 ID:20161116030212

This has been triaged, it's one of the async plugin bugs. no ownership yet since we are waiting on other fixes to land.

Too late for 51, mark 51 as won't fix.

input and rendering profile: https://perfht.ml/2l0hwT7

(In reply to Jim Mathies [:jimm] from comment #8) > input and rendering profile: > https://perfht.ml/2l0hwT7 This site is a good test case for input delays. AFAICT we're actually doing ok perf wise. External to us though one of the flash processes is consuming 75% or more of the cpu, which drags everything down.

(In reply to Jim Mathies [:jimm] from comment #9) > (In reply to Jim Mathies [:jimm] from comment #8) > > input and rendering profile: > > https://perfht.ml/2l0hwT7 > > This site is a good test case for input delays. AFAICT we're actually doing > ok perf wise. External to us though one of the flash processes is consuming > 75% or more of the cpu, which drags everything down. This said, flipping back to windowed mode I see the same cpu use, but in that case input is processed in a more timely way.