1314935 - Flash game would not respond with key / mouse

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Alice0775 White]

[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.

Comment 1

[Jim Mathies [:jimm]]

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.

Comment 2

[Tracy Walker [:tracy]]

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.

Comment 3

[Gerry Chang [:gchang]]

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

Comment 4

[Gerry Chang [:gchang]]

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

Comment 5

[Alice0775 White]

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

Comment 6

[Jim Mathies [:jimm]]

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

Comment 7

[Gerry Chang [:gchang]]

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

Comment 8

[Jim Mathies [:jimm]]

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

Comment 9

[Jim Mathies [:jimm]]

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

Comment 10

[Jim Mathies [:jimm]]

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