1151644 - Window renders blank with layers.acceleration.disabled set to true

Status: VERIFIED FIXED

(Core :: Graphics: Layers, defect)

Description

[u279076]

In a recent Nightly we regressed Layers. The window just renders blank if layers is disabled on Mac. I've traced this back to the following window on mozilla-central.

Last Good: 2015-03-26 [37d3dcbf23a9]
First Bad: 2015-03-27 [e046475a75cb]
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=37d3dcbf23a9&tochange=e046475a75cb

I'll try to regress this further.

[Tracking Requested - why for this release]: this is a pretty serious usability regression for people with Layers disabled.

Comment 1

[u279076]

Tinderbox regression window
===========================
Last Good: 20150325130909 [f40ee067d081]
First Bad: 20150325165811 [37d3dcbf23a9]
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40ee067d081&tochange=37d3dcbf23a9

Comment 2

[Tim Kuijsten]

Does this bug have anything to do with the rendering mixing up content when scrolling? I think that regression started for me by the end of March. Since then I'm on Aurora but since the upgrade to 39a2 I've the same problems again.

Comment 3

[u279076]

(In reply to Tim Kuijsten from comment #2)
> Does this bug have anything to do with the rendering mixing up content when
> scrolling? 

As far as I can tell this is nothing to do with scrolling as the bug happens immediately on startup without any user interaction whatsoever.

Comment 4

[:kip (Kearwood Gilbert)]

I have reproduced this bug on OSX but it does not appears to affect Linux.

Comment 5

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

Possibly a dup of bug 1151492.

Comment 6

[Tim Kuijsten]

Currently I have the same problem with nightly, complete white page, white dialogs, not usable at all.

The artifacts that show up when scrolling as I've reported earlier is what I currently experience with 39a2 and previously with 39a1 (it made me downgrade from 39a1 to 38a2 at the time).

Comment 7

[u279076]

Tim, you should be able to work around this by setting layers.acceleration.disabled to false in about:config. If there is some other reason you need to keep Layers disabled then my recommendation would be to switch to Dev Edition until this is resolved.

Comment 8

[Tim Kuijsten]

That indeed does the trick.

I've heard some rumor about some security risks that might come with hardware acceleration. That's the reason I've disabled it but I haven't been able to really find out if this is true or what this claim is based upon. For now I'm on Dev.

Comment 9

[u279076]

I am not aware of the security risks you mention but I'm also not a technical expert on this feature. If you have serious concerns I would recommend you write a post to [e-mail] explaining these concerns so you can get insight directly from the people writing the code.

Comment 10

[Tim Kuijsten]

Tnx! As soon as I'll see some messages around the topic, I'll contact them.

Comment 11

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

Don't think the regression range is the correct one, at least comment 0 and comment 1 have conflicting info (notice that the last good from comment 0 is the same change as the first bad from comment 1.)
This seems to be it for me, but only if I have "Use hardware acceleration when available" disabled; in other words, when bug 1151491 kicks in.

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da2f28836843&tochange=e5b72a8edb82

In particular, bug 1125848.

So, the question is, do others see this problem when "Use hardware acceleration when available" is left at the default value of enabled?

Comment 12

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

So, it looks like the third (not uplifted) patch to bug 1125848 broke the basic layers on OS X.

Comment 13

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] from comment #12)
> So, it looks like the third (not uplifted) patch to bug 1125848 broke the
> basic layers on OS X.

Huh, weird. I'll try to get my hand on a mac and debug this. If I don't figure it out in the next few days, I'll back the patch out.

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

Bug 1153794 might be a dupe of this. I think h/w acceleration is being disabled by blocking a bad driver, layers.acceleration.disabled is already false and flipping it has no effect.

Comment 16

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

Tracking for 39+.

Comment 17

[Nicolas Silva [:nical]]

We are trying to create a compositor with no backend, which inevitably fails. On the client side we go thorugh this: https://dxr.mozilla.org/mozilla-central/source/widget/nsBaseWidget.cpp?from=nsBaseWidget.cpp#1145

Which removes the basic backend from the list of backends (and we end up shipping a list with no backends at all which is just silly). I think that we don't need this logic anymore (it was added back when the basic compositor wasn't usable). It's harmless to remove this now (and removing it fixes the issue).
What bug 1125848 has probably caused, is that mRequireOffMainThreadCompositing is false although it should be true, but I haven't yet identified why.

Comment 18

[Nicolas Silva [:nical]]

Attachment: stop disallowing the basic backend.

Comment 19

[Stefan [:stefanh]]

Comment on attachment 8592854 [details] [diff] [review]
stop disallowing the basic backend.

I tried this patch on 10.9, and it worked fine. But I then ran the build on an old Mac mini with 10.6.8 (GMA 950 chip) and I still see the issue. I then tried a nightly from 2015-03-30 on the same system and it worked fine.

This is the Graphics section from about:support:
Asynchronous Pan/Zoom	none
GPU Accelerated Windows	0/1 Basic
WebGL Renderer	Apple Computer, Inc. -- Apple Software Renderer
windowLayerManagerRemote	false
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

Comment 20

[Stefan [:stefanh]]

Attachment: log.txt

Console output when running on 10.6.8 with intel GMA 950

Comment 21

[Stefan [:stefanh]]

Just to clarify: I see the issue regardless of layers.acceleratin.disabled is set to true or false and I access this Mac from the 10.9 machine with Screen sharing.

Comment 22

[:kip (Kearwood Gilbert)]

This patch worked for me on OSX 10.10.3.  My graphics section from about:support:

Asynchronous Pan/Zoom      none
Device ID                  0xfe9
GPU Accelerated Windows    0/1 Basic (OMTC)
Vendor ID                  0x10de
WebGL Renderer             NVIDIA Corporation -- NVIDIA GeForce GT 750M OpenGL Engine
windowLayerManagerRemote   true
AzureCanvasBackend         skia
AzureContentBackend        quartz
AzureFallbackCanvasBackend none
AzureSkiaAccelerated       0

Comment 23

[u279076]

(In reply to Stefan [:stefanh] from comment #21)
> Just to clarify: I see the issue regardless of layers.acceleratin.disabled
> is set to true or false and I access this Mac from the 10.9 machine with
> Screen sharing.

Can you confirm if the regression window in comment 0 is relevant for that use case? If not then you might be seeing a different bug with similar symptoms.

Comment 24

[Stefan [:stefanh]]

> Can you confirm if the regression window in comment 0 is relevant for that
> use case?

But is that the right regression window (comment #11)? As I said, it works for me with a nightly from 2015-03-30 and according to comment #12 and looking at bug 1125848, comment #63 this seems to have regressed 2015-04-01. I can check 2015-03-31 and 2015-04-01, though.

Comment 25

[Stefan [:stefanh]]

OK, so I checked when it regressed on the 10.6.8 machine (from ftp://ftp.mozilla.org/../pub/firefox/nightly/):
Good: 2015-03-31-03-02-04-mozilla-central
Bad: 2015-04-01-18-09-20-mozilla-central

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

That's what I had in bug 1153794 too, on 10.7.5 with an old machine that is blocklisted from acceleration. Attachment 8592854 [details] [diff] also resolves the problem for me (try build at  http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f428e02f6acc/try-macosx64/ if anyone wants it).

Comment 27

[Nicolas Silva [:nical]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c20a7ab389ff

Comment 28

[Stefan [:stefanh]]

Looking at widget/cocoa/GfxInfo.mm, it looks like GMA 950 isn't blocklisted. Perhaps this is a separate issue then. I'll investigate a bit more in a few days (no time until the weekend) - I can file a new bug then.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c20a7ab389ff

Comment 31

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

Anthony can you verify the fix on 40? It would be good to verify this works before we try uplifting it to 39.

Comment 32

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

Fixed it for me on 40, OS X 10.9.5

Comment 33

[Tim Kuijsten]

fixed for me :) OS X 10.10.3

Comment 34

[Stefan [:stefanh]]

This doesn't work for me with the 10.6.8 machine with GMA 950 and I'm not sure about comment #28 anymore...

I tracked down the 10.6.8/GMA 950 regression by using mozilla-inbound tinderbox builds and the first bad build is built from https://hg.mozilla.org/integration/mozilla-inbound/rev/295db120bf12 which is the third patch in bug 1125848.

Do you want a new bug for this? I mean it's obviously quite old hardware (I use it for testing patches on 10.6.8).

Comment 35

[Nicolas Silva [:nical]]

(In reply to Stefan [:stefanh] from comment #34)
> Do you want a new bug for this? I mean it's obviously quite old hardware (I
> use it for testing patches on 10.6.8).

Yes, that would be good.

Comment 36

[Stefan [:stefanh]]

(In reply to Nicolas Silva [:nical] from comment #35)
> (In reply to Stefan [:stefanh] from comment #34)
> > Do you want a new bug for this? I mean it's obviously quite old hardware (I
> > use it for testing patches on 10.6.8).
> 
> Yes, that would be good.

Filed bug 1156833.

Comment 37

[Lawrence Mandel [:lmandel] (use needinfo)]

Nical - Looks like this fix is good and we'll handle follow up in bug 1156833. 39 is marked as affected. What do you think about uplifting this fix to Aurora?

Comment 38

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

The original patch that regressed this never landed beyond 40, so I'm not convinced 39 is affected, although the problem may have existed there.

Comment 39

[Nicolas Silva [:nical]]

Comment on attachment 8592854 [details] [diff] [review]
stop disallowing the basic backend.

In doubt, the patch is trivial and also correct on aurora.

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: firefox may be unusable for some people on mac with layers acceleration disabled or blacklisted.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: Low risk: removes a piece of code that makes no sense any more.
[String/UUID change made/needed]:

Comment 40

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8592854 [details] [diff] [review]
stop disallowing the basic backend.

Even though there is some doubt of the need for this uplift, I'd like to take it speculatively. Aurora+

Comment 41

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d3e683848887

Comment 42

[u279076]

I confirm this has been resolved in the latest Firefox 40.0a1 and 39.0a2 builds.

Comment 43

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

Fabulous. Thanks Anthony.