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.
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.
Component: Untriaged → Plug-ins
Keywords: flashplayer, perf, regression
Product: Firefox → Core
Duplicate of this bug: 1394107
How is that disabled
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.
[Tracking Requested - why for this release]: A performance regression from Firefox 55. AFAIK not everyone is affected, but some people are observing the regression.
status-firefox55: --- → affected
status-firefox56: --- → ?
status-firefox57: --- → ?
tracking-firefox55: --- → ?
tracking-firefox56: --- → ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: 55.0.3 - performance of Shockwave Flash content has dropped significantly, with web based flash running very slowly and saved .swf files not loading at all. → Firefox 55 - performance of Shockwave Flash content has dropped significantly, with web based flash running very slowly, disabling async drawing solves the issue
Duplicate of this bug: 1394142
Duplicate of this bug: 1394295
Sorry for duplicate. I also did what thelink225 did and now it works.
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.
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?
status-firefox-esr52: --- → unaffected
There are actually several more Flash regressions in 55, including: Bug 1347575 Bug 1392922 Bug 1393352 Bug 1393724 Bug 1394015 Bug 1394024 Bug 1394091
Track 56+ as perf regression for now.
tracking-firefox56: ? → +
Can you provide a link to the affected flash site?
One of the duplicates, Bug 1394142, lists the following games: > Start 2 Flash Application: > Forge of Empires > Siedleronline
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...
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.
Jim, any ideas given Comment #14.
Severity: normal → critical
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?
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)
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/
Keywords: dev-doc-complete, user-doc-needed
(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.
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 .  https://wiki.mozilla.org/Firefox/Win64
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 :(
(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 . > >  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.
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.
(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.
Too late for a fix for 56.
status-firefox55: affected → wontfix
status-firefox56: ? → wontfix
status-firefox57: ? → fix-optional
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.