1394105 - Firefox 55 - performance of Shockwave Flash content has dropped significantly, with web based flash running very slowly, disabling async drawing solves the issue

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[thelink225]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

This issue began immediately after the 55.0.3 update. It occurs anytime I open a Shockwave Flash-based game which requires any sort of input (keyboard or mouse) from any location. Changing plugin settings for Shockwave Flash, restarting my browser, and even restarting my computer did not change the results.


Actual results:

If the flash game was opened from an online web page (IE: Armor Games, Newgrounds), the game would run slowly and it would cause the entire browser to hang for around a minute most of the times that it was wanting some kind of input or interaction from the player. It would run, but very poorly. If the flash game was opened from an .swf file stored on my hard drive, it wouldn't open at all. It would only open up to a blank browser tab.


Expected results:

These games should have opened and operated as normal, without lag or hanging, as they were doing literally minutes before the 55.0.3 update. The game I was playing before the update, which was a saved .swf file that I have played many times before, was working normally immediately before the update, but immediately after would no longer open or function.

Comment 1

[Kohei Yoshino [:kohei]]

Local .swf files will no longer be loaded on Firefox 55, as noted in https://www.fxsitecompat.com/en-CA/docs/2017/flash-can-now-be-loaded-only-from-http-https/

One user says disabling async drawing solved the performance issue.

Comment 3

[daveweirup]

How is that disabled

Comment 4

[thelink225]

Well, I got it to work right. I typed about:config into the address line of the browser to open the hidden options. I toggled plugins.http_https_only to 'false' in order to disable the annoying function that keeps it from loading local .swf files. I can now load them with no problem, as I previously could.

I disabled the async drawing in the same about:config menu. You have to toggle both dom.ipc.plugins.asyncdrawing.enabled and dom.ipc.plugins.forcedirect.enabled to false. This fixed the performance issues. My flash now runs as it did before. Thanks, Kohei Yoshino for pointing me in the right direction AND cluing me in to the hidden about:config menu.

Comment 5

[Kohei Yoshino [:kohei]]

[Tracking Requested - why for this release]: A performance regression from Firefox 55. AFAIK not everyone is affected, but some people are observing the regression.

Comment 8

[Signe Johnsen]

Sorry for duplicate. 

I also did what thelink225 did and now it works.

Comment 9

[Kohei Yoshino [:kohei]]

There aren't so many reports yet probably because most users are still on Firefox 54, but I think it's better to disable async drawing ASAP until further investigation is done. Ccing people from Bug 1340934.

Comment 10

[Chris Peterson [:cpeterson]]

thelink225, can you please share your about:support information in this bug? Can you provide a link to a specific Flash game that demonstrates the performance problem?

Comment 11

[Kohei Yoshino [:kohei]]

There are actually several more Flash regressions in 55, including:

Bug 1347575
Bug 1392922
Bug 1393352
Bug 1393724
Bug 1394015
Bug 1394024
Bug 1394091

Comment 12

[Gerry Chang [:gchang]]

Track 56+ as perf regression for now.

Comment 13

[Jim Mathies [:jimm]]

Can you provide a link to the affected flash site?

Comment 14

[Kohei Yoshino [:kohei]]

One of the duplicates, Bug 1394142, lists the following games:

> Start 2 Flash Application:
> Forge of Empires
> Siedleronline

Comment 15

[Kohei Yoshino [:kohei]]

It's been confirmed that async drawing is causing at least this bug and Bug 1347575. The firefox55 tracking flag is not set yet, but this bug is among the Firefox 55 auto update stoppers. I'd again suggest disabling it first...

Comment 16

[Chris Peterson [:cpeterson]]

Ritu, this is a Flash regression in Windows 32-bit Firefox. We might want to disable the Flash async drawing feature in 55 if Jim can confirm the problem.

Comment 17

[Mike Taylor [:miketaylr]]

Jim, any ideas given Comment #14.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Until we're able to address this, I wonder if folks from SUMO could help write up a page on the problem and the workaround. Noah, is this something you might take on?

Comment 19

[Kohei Yoshino [:kohei]]

There are a couple of workarounds IIUC:

* Enable hardware acceleration via Flash Player's Settings: https://forums.adobe.com/thread/891337
* Switch to the 64-bit version of Firefox (re-install the browser)
* Change the dom.ipc.plugins.asyncdrawing.enabled pref to false (not recommended)

Comment 20

[Kohei Yoshino [:kohei]]

Here's my site compatibility note for web developers (not for users): https://www.fxsitecompat.com/en-CA/docs/2017/some-flash-contents-including-games-and-video-players-are-broken-on-firefox-55/

Comment 21

[Jim Mathies [:jimm]]

(In reply to Chris Peterson [:cpeterson] from comment #16)
> Ritu, this is a Flash regression in Windows 32-bit Firefox. We might want to
> disable the Flash async drawing feature in 55 if Jim can confirm the problem.

This seem premature. We expect some perf regression from async but we really want the feature.

Comment 22

[Kohei Yoshino [:kohei]]

Why do you think this seems premature? This bug is a confirmed perf regression with 3 duplicates, and there are 10+ regression bugs reported overall for the async drawing (see my comment 11) including some tab switching issues being tracked in meta bug 1394408. I know it's a great progress and I know everyone is busy with Firefox 57, but no one wants to lose users, right? 

To mitigate the negative effects, I believe it's not too late to re-enable the pref with Firefox 56.0.1 coming October when the majority of Windows users will automatically be migrated to the 64-bit version [1].

[1] https://wiki.mozilla.org/Firefox/Win64

Comment 23

[Kohei Yoshino [:kohei]]

Forgot to mention: so far Flash click-to-activate has been enabled only for 5% of the user base (will be 25% in Bug 1390703 sometime soon) so people don't realize that their slowness, hang or other glitch is due to Flash Player. Instead they just blame Firefox :(

Comment 24

[Jim Mathies [:jimm]]

(In reply to Kohei Yoshino [:kohei] from comment #22)
> Why do you think this seems premature? This bug is a confirmed perf
> regression with 3 duplicates, and there are 10+ regression bugs reported
> overall for the async drawing (see my comment 11) including some tab
> switching issues being tracked in meta bug 1394408. I know it's a great
> progress and I know everyone is busy with Firefox 57, but no one wants to
> lose users, right? 
> 
> To mitigate the negative effects, I believe it's not too late to re-enable
> the pref with Firefox 56.0.1 coming October when the majority of Windows
> users will automatically be migrated to the 64-bit version [1].
> 
> [1] https://wiki.mozilla.org/Firefox/Win64

First it's expected that some flash applets that have a particular wmode setting may experience a performance regression due to async painting. In general though most users should see performance that is on par with the performance they experienced before the feature was enabled.

We currently have the following reported:

1) a known painting bug related to window/tab changes (bug 1394408)
2) an new input bug related to maximized windows (bug 1394918).

There are three perf/freezing bugs attached here, in two of which I've asked for about:support info from reporters. 

We need to get the painting bug fixed, I'm looking at that now.

Comment 25

[Kohei Yoshino [:kohei]]

I'm observing Japanese Twitter/Firefox users and they are mainly talking about white text issue reported in Bug 1347575 / Bug 1393352. Since nicovideo is (one of) the most popular live streaming site in Japan, many people are being affected.

Comment 26

[Jim Mathies [:jimm]]

(In reply to Kohei Yoshino [:kohei] from comment #25)
> I'm observing Japanese Twitter/Firefox users and they are mainly talking
> about white text issue reported in Bug 1347575 / Bug 1393352. Since
> nicovideo is (one of) the most popular live streaming site in Japan, many
> people are being affected.

Adobe is looking at this issue currently.

Comment 27

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix for 56.