1306465 - Remove D3D9 default fallback on Firefox 49/50

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[George Wright (:gw280) (needinfo me!)]

Spin-off from bug 1304360.

Comment 1

[George Wright (:gw280) (needinfo me!)]

Attachment: 0001-Bug-1306465-Disable-d3d9-fallback-by-default.patch

This would need to be applied to only fx 49 and 50, as I understand it.

Comment 2

[George Wright (:gw280) (needinfo me!)]

Comment on attachment 8796614 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1262187
[User impact if declined]: graphical artifacts when browsing, see bug 1304360
[Describe test coverage new/current, TreeHerder]: manual QA
[Risks and why]: should be none. it just removes the d3d9 accelerated fallback option and falls back to software, which is a very well-tested codepath. 
[String/UUID change made/needed]: none

Comment 3

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8796614 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default.patch

Taking this fix in 50.0b4 as it should address a Beta50 top crasher.

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/2f52a44aaffa

If this doesn't actually mean the bug is fixed, feel free to reopen. :)

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment on attachment 8796614 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default.patch

We don't want users moving to other browsers, and this is a preference change to go back to the original pre-49 behaviour.

Comment 6

[Milan Sreckovic [:milan] (needinfo for best results)]

Some documentation on the complaints: https://input.mozilla.org/en-AU/?q=stretch&product=Firefox&date_end=2016-10-05&date_start=2016-09-11

Comment 7

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

Looks like this does not fix a crash but it may fix the graphics artifact issues described in bugs 1304360, 1306689, and 1306953. (Are there more?) And, before 49, we had some people on D3D9, some on D3D11, and some without hardware acceleration. With 49, we moved some of the people with *no* HWA to D3D9. As I understand it, we would be undoing at least some (or all?) of that move with this pref flip.

Can we verify that these issues are now fixed in beta? 
Is this something we could fix on release with a system addon or hotfix?

Comment 8

[Peter Dolanjski [:pdol]]

Attachment: about:support graphics info

I reproduced the issue on a family member's computer.
Windows 7 on release 49.0.1.

See attached image for about:support graphics info prior to me changing the layers.allow-d3d9-fallback pref to false.

Comment 9

[Peter Dolanjski [:pdol]]

Attachment: about:support graphics info (after pref change to false)

Attached is about:support graphics info after changing layers.allow-d3d9-fallback to false.

The issue is fixed after changing this pref and restarting Firefox.

Comment 10

[Peter Dolanjski [:pdol]]

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #7)
> Can we verify that these issues are now fixed in beta? 
> Is this something we could fix on release with a system addon or hotfix?

I tried 50.0b4 on the machine that had the issue on release 49.  It looks to be fixed (and I verified that the layers.allow-d3d9-fallback pref is set to false (as the default).

Given that this is a pretty significant experience issue that's happening on release for up to 5% of users (per Milan), we need to fix on release in some manner.

Comment 11

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

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Suggested wording]:
[Links (documentation, blog post, etc)]:

Marking this as a blocking bug for 49 to indicate we should make fixing this a priority and not wait till 50.   

In the meantime we may want to get out word about  how to work around it (turn off the d3d9 fallback pref) on support.mozilla.org. Rachel, I wonder if you can write something for SUMO?  I could also add it to the release notes as a known issue for 49.

Comment 12

[Peter Dolanjski [:pdol]]

Milan had asked me to try setting layers.allow-d3d9-fallback back to true, reproducing the issue then setting layers.componentalpha.enabled to false and restarting.

This also seems to fix the problem.

Comment 14

[Milan Sreckovic [:milan] (needinfo for best results)]

Will take care of the fix for 49 in bug 1309330.

Comment 15

[Joni Chan]

We've started a SUMO article draft that the community can link to in the support forums and on social between now until the add-on has shipped. Can someone help us with the instructions? https://docs.google.com/document/d/1iZrKgqWvNSG5X8Zz5w9qm7OjSw9cVEg_r2Gl7LIzXio/edit?usp=sharing 

The first version will have about:config instructions. When the add-on has been tested and shipped, we'll replace about:config with steps for installing the add-on.

Comment 16

[Milan Sreckovic [:milan] (needinfo for best results)]

The add-on is a system one, do we need separate instructions on installing it?  Anyway, the instructions look good.  If we believe there are people for which about:config is too complicated of a set of instructions, just turning the acceleration off in the Advanced preferences will accomplish the same.  However, the about:config and layers.allow-d3d9-fallback is a much preferred approach.

Comment 17

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

The instructions are for people hitting the issue now.  Hopefully, once we release the system add-on, they won't see this problem any more. But until then they can use the workaround. Thanks Joni and philipp, the article looks helpful!

Comment 18

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

Comment on attachment 8796614 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default.patch

Since we are shipping this as a system addon, we also want to land it on mozilla-release (for 49.0.2, likely next week)

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/25e8a5c6be62

Comment 20

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

Change D3D9 default fallback preference to prevent graphical artifacts (Bug 1306465)

Comment 21

[:Felipe Gomes (needinfo for replies!)]

This landed on beta 50 (comment 4) and release 49 (comment 19). Can this bug be closed now?

Comment 22

[Yorgos]

what did you do?
after unstalling 49.0.2 I see black windown in Flash (full screen mode only).
49.0.1 Perfect.

Comment 23

[Yorgos]

dom.ipc.plugins.asyncdrawing.enabled to false, fixed the issue arised after upgrading to 49.0.2
(thanks Steuber for the suggestion).

Comment 24

[Terrell Kelley]

I also had to disable this so the video player on fivethirtyeight.com would work. 

Sample URL: http://fivethirtyeight.com/features/late-night-podcast-a-nasty-third-debate/
scroll down to find the video.

The video itself is HTML5. However, if the user has Flash installed, then a Flash Object is placed on top the video for ad purposes. While the ad will play, the video itself will be covered in white. Only the controls work.

I would guess that the problem has something to do with transparency or possibly even how you handle the wmode.

Comment 25

[Alice0775 White]

(In reply to Terrell Kelley from comment #24)
> I also had to disable this so the video player on fivethirtyeight.com would
> work. 
> 
> Sample URL:
> http://fivethirtyeight.com/features/late-night-podcast-a-nasty-third-debate/
> scroll down to find the video.
> 
> The video itself is HTML5. However, if the user has Flash installed, then a
> Flash Object is placed on top the video for ad purposes. While the ad will
> play, the video itself will be covered in white. Only the controls work.
> 
> I would guess that the problem has something to do with transparency or
> possibly even how you handle the wmode.

I have filed Bug 1311928

Comment 26

[Milan Sreckovic [:milan] (needinfo for best results)]

George, let's push this patch to 51 and nightly as well.  Once bug 1309277 is fixed, we can flip that preference back.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9459cdff732a
Disable d3d9 fallback by default r=milan

Comment 28

[George Wright (:gw280) (needinfo me!)]

Attachment: 0001-Bug-1306465-Disable-d3d9-fallback-by-default-r-milan.patch

Carrying forward review from previous patch (functionally identical, this is rebased on m-c and should apply to aurora too)

Comment 29

[George Wright (:gw280) (needinfo me!)]

Comment on attachment 8805153 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default-r-milan.patch

Approval Request Comment
[Feature/regressing bug #]: bug 1304360 and bug 1306689
[User impact if declined]: graphical artifacting due to bad fallback when using hardware acceleration
[Describe test coverage new/current, TreeHerder]: this has been on release, beta and nightly for a while, see comment 2
[Risks and why]: same as comment 2
[String/UUID change made/needed]: none

Comment 30

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/9459cdff732a

Comment 31

[Gerry Chang [:gchang]]

Comment on attachment 8805153 [details] [diff] [review]
0001-Bug-1306465-Disable-d3d9-fallback-by-default-r-milan.patch

Disable d3d9 fallback. Take it in 51 aurora.

Comment 32

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/70025dbda133

Comment 43

[Mark Banner (:standard8)]

Restricting comments as this is long closed & has become a spam trap.