Last Comment Bug 1312528 - Disable async rendering by default on 49.0.2 using a system addon
: Disable async rendering by default on 49.0.2 using a system addon
Status: RESOLVED FIXED
[fce-active][go-faster-system-addon]
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: Unspecified Unspecified
: -- normal with 1 vote (vote)
: ---
Assigned To: Kirk Steuber [:bytesized]
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
Depends on: 1307108 1309037
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-24 12:35 PDT by Benjamin Smedberg [:bsmedberg]
Modified: 2016-11-01 13:35 PDT (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
blocking
fixed


Attachments
async_pref.patch (1.32 KB, patch)
2016-10-24 17:00 PDT, Kirk Steuber [:bytesized]
felipc: review+
Details | Diff | Splinter Review
async_addon.patch (3.62 KB, patch)
2016-10-24 17:00 PDT, Kirk Steuber [:bytesized]
felipc: review+
Details | Diff | Splinter Review
async_rendering.xpi (1.31 KB, application/x-xpinstall)
2016-10-24 17:01 PDT, Kirk Steuber [:bytesized]
no flags Details
async_rendering.signed.xpi (5.26 KB, application/x-xpinstall)
2016-10-25 14:14 PDT, :wezhou
no flags Details

Description User image Benjamin Smedberg [:bsmedberg] 2016-10-24 12:35:42 PDT
+++ This bug was initially created as a clone of Bug #1307108 +++

Async/direct plugin rendering has many regressions, and we need to turn it off in 49.0.2 (sorry!). 

Please implement the same pref flip as bug 1307108 but in reverse to disable.

This addon should be deployed to windows 32-bit only. We do *not* intend to deploy this to windows 64-bit, because it would cause more serious regressions in scrolling and IME support.
Comment 1 User image Cory Price [:ckprice] 2016-10-24 14:53:19 PDT
Please do keep the gofaster@mozilla.org mailing list updated with progress on intention to implement/ship[0].

[0] https://wiki.mozilla.org/Firefox/Go_Faster/Process#Process_to_Push_updates_to_release_channel
Comment 2 User image Kirk Steuber [:bytesized] 2016-10-24 17:00:40 PDT
Created attachment 8804090 [details] [diff] [review]
async_pref.patch
Comment 3 User image Kirk Steuber [:bytesized] 2016-10-24 17:00:59 PDT
Created attachment 8804091 [details] [diff] [review]
async_addon.patch
Comment 4 User image Kirk Steuber [:bytesized] 2016-10-24 17:01:27 PDT
Created attachment 8804092 [details]
async_rendering.xpi
Comment 5 User image Michelle Funches - QA 2016-10-25 10:12:46 PDT
QA Update: I will be running some test to ensure the addon works - currenlty I cannot install the addon "Firefox has prevented this site from installing and unverified addon" - Will there be a signed XPI?
Comment 6 User image Kirk Steuber [:bytesized] 2016-10-25 10:15:30 PDT
I will get the addon signed after it has passed review.
Comment 7 User image DEXTER 2016-10-25 11:03:38 PDT
Fix this on Win10x64 too!
Comment 8 User image funoplay 2016-10-25 11:19:46 PDT
The worry is that right now these performance issues render so many popular games and sites unplayable. It's a big deal as millions access these games daily. The experience of users at http://www.friv.com for example is affected the point where even clicking on a game is near impossible owing to the lag. Friv is a world top 500 site. I'd echo Dexter above "Fix this on Win10x64 too!" Thanks guys.
Comment 9 User image Kirk Steuber [:bytesized] 2016-10-25 12:17:29 PDT
My understanding is that the other regressions are serious enough that we consider this necessary despite performance regressions. @bsmedberg Can you confirm?
Comment 10 User image Liz Henry (:lizzard) (needinfo? me) 2016-10-25 12:32:05 PDT
We definitely want to fix the issues for win64 too, but that fix will land in the Firefox 50 release which will happen Nov. 8th.  Since that happens in just a couple of weeks, it is best to wait for Firefox 50 to come out. The Firefox beta 50 that is planned to release later this week (Friday) should also work for win64 users. 

For win32, we can disable async rendering with this system add-on/hotfix; For win64 there are bigger code changes, so we'd need to ship a full release to fix async rendering/plugin drawing.
Comment 11 User image Chris 2016-10-25 12:57:41 PDT
All affected devs from flash games: changing the wmode to "gpu" helps so far very good, and accellerates the game.
Comment 12 User image :Felipe Gomes (needinfo me!) 2016-10-25 13:24:36 PDT
Comment on attachment 8804092 [details]
async_rendering.xpi

(no need to review the xpi)
Comment 13 User image Kirk Steuber [:bytesized] 2016-10-25 13:26:59 PDT
Comment on attachment 8804092 [details]
async_rendering.xpi

@jason Could I get this XPI signed please?
Comment 14 User image :wezhou 2016-10-25 14:14:52 PDT
Created attachment 8804461 [details]
async_rendering.signed.xpi

The file is signed.
Comment 15 User image Michelle Funches - QA 2016-10-25 15:23:45 PDT
QA Update: The system addon to revert does what it is supposed to do. 
Test: Windows 7, Windows 8.1, Windows 10 with Firefox 32bit
Comment 16 User image Cory Price [:ckprice] 2016-10-25 16:00:08 PDT
The release-sysaddon channel has been updated as follows and is ready for testing.

The rule shipping to 49.0.2 has been modified to ship the following add-on (there were previously no system add-ons shipping to this version).

- asyncrendering-2.0 (bug 1312528)
Comment 17 User image Andrew Gurskiy 2016-10-26 07:44:38 PDT
Hi.

I installed async_rendering.signed.xpi and default value for dom.ipc.plugins.asyncdrawing.enabled changed to false. But  I still have issue with game performance on non debug version of Flash player version 23.0.0.205.

After restarting browser and computer I have the same result.

You can check by yourself - https://apps.facebook.com/slotomania

Best regards,
Slototmania TL 
Andrew Gurskiy
Comment 18 User image Kirk Steuber [:bytesized] 2016-10-26 08:55:11 PDT
Andrew - If your problems are independent of the |dom.ipc.plugins.asyncdrawing.enabled| pref, they are likely unrelated to this bug. You should file a separate bug for your issue.
Comment 19 User image Cory Price [:ckprice] 2016-10-26 10:57:24 PDT
The following has been moved to the *release* channel

- 49.0/49.0.1 will now receive asyncrendering-2.0 instead of 1.0. No other changes.
- 49.0.2 will receive asyncrendering-2.0.
Comment 20 User image Alice0775 White 2016-10-28 08:59:38 PDT
Is the addon shipped already?
How I can confirm?
Comment 21 User image Benjamin Smedberg [:bsmedberg] 2016-10-28 09:02:11 PDT
It should be shipped to 49.0.2 per comment 19. Check about:support to see if the addon is present and then the pref values.
Comment 22 User image Alice0775 White 2016-10-28 09:33:37 PDT
(In reply to Benjamin Smedberg [:bsmedberg] from comment #21)
> It should be shipped to 49.0.2 per comment 19. Check about:support to see if
> the addon is present and then the pref values.

I open Firefox49.0.2 for a day. But it is not present in about:support.
The prefs is still true.

Why do not 49.0.3 release?
Comment 23 User image Kirk Steuber [:bytesized] 2016-10-28 09:36:50 PDT
Alice0775 - I believe that the changes do not show up until the browser is restarted.
Comment 24 User image Alice0775 White 2016-10-28 09:54:34 PDT
(In reply to Kirk Steuber [:bytesized] from comment #23)
> Alice0775 - I believe that the changes do not show up until the browser is
> restarted.

Just now, I restart the browser. But nothing is changed.
Comment 25 User image :Felipe Gomes (needinfo me!) 2016-10-28 10:14:52 PDT
Alice, do you have automatic Firefox updates disabled?
Comment 26 User image Alice0775 White 2016-10-28 10:28:47 PDT
Yes, I set "Never check for updates (not recommended: security risk)"
Comment 27 User image Alice0775 White 2016-10-28 10:39:51 PDT
Start Firefox49.0.2 with new profile and restart. But, the addon is not present. And the rpef is still true. Why?

So, User cannot control to get system addon. Anyway, I think hotfix system is not good solution.
Comment 28 User image :Felipe Gomes (needinfo me!) 2016-10-28 10:40:08 PDT
Ok, so that's the reason. This is being tracked by bug 1307563 but there's no clear solution yet.
Comment 29 User image Alice0775 White 2016-10-28 10:48:21 PDT
(In reply to :Felipe Gomes (needinfo me!) from comment #28)
> Ok, so that's the reason. This is being tracked by bug 1307563 but there's
> no clear solution yet.

Yes. That is.

How about comment#27?
Comment 30 User image :Felipe Gomes (needinfo me!) 2016-10-28 11:19:45 PDT
(In reply to Alice0775 White from comment #29)
> (In reply to :Felipe Gomes (needinfo me!) from comment #28)
> > Ok, so that's the reason. This is being tracked by bug 1307563 but there's
> > no clear solution yet.
> 
> Yes. That is.
> 
> How about comment#27?

And that point is tracked by bug 1307553
Comment 31 User image Alice0775 White 2016-10-28 11:28:42 PDT
Thanks
Comment 32 User image Liz Henry (:lizzard) (needinfo? me) 2016-11-01 13:35:40 PDT
This was shipped last week, marking fixed for 49 and fixed overall. 

Please note that this is for win32 only.  If you are waiting on a fix for win64, please try the latest beta 50 version, currently beta 11: https://www.mozilla.org/en-US/firefox/channel/desktop/. 
The fix for win64 on the release channel should be available Nov. 15th.

Note You need to log in before you can comment on or make changes to this bug.