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

VERIFIED FIXED in Firefox 39

Status

()

Core
Graphics: Layers
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: ashughes, Assigned: nical)

Tracking

(Depends on: 1 bug, {regression})

Trunk
mozilla40
x86
Mac OS X
regression
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox37 unaffected, firefox38 unaffected, firefox39 verified, firefox40 verified)

Details

(Whiteboard: gfx-noted)

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 1

3 years ago
Tinderbox regression window
===========================
Last Good: 20150325130909 [f40ee067d081]
First Bad: 20150325165811 [37d3dcbf23a9]
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40ee067d081&tochange=37d3dcbf23a9
Keywords: regressionwindow-wanted
(Reporter)

Updated

3 years ago
status-firefox39: unaffected → affected

Comment 2

3 years ago
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.
(Reporter)

Comment 3

3 years ago
(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.
I have reproduced this bug on OSX but it does not appears to affect Linux.
Possibly a dup of bug 1151492.

Comment 6

3 years ago
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).
(Reporter)

Comment 7

3 years ago
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

3 years ago
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.
(Reporter)

Comment 9

3 years ago
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 dev-platform@lists.mozilla.org explaining these concerns so you can get insight directly from the people writing the code.

Comment 10

3 years ago
Tnx! As soon as I'll see some messages around the topic, I'll contact them.
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?
Whiteboard: gfx-noted
See Also: → bug 1151492
So, it looks like the third (not uplifted) patch to bug 1125848 broke the basic layers on OS X.
(Assignee)

Comment 13

3 years ago
(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.
Assignee: nobody → nical.bugzilla

Updated

3 years ago
Duplicate of this bug: 1153843
Blocks: 1153724
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.

Updated

3 years ago
See Also: → bug 1153794

Updated

3 years ago
See Also: → bug 1150756
Tracking for 39+.
tracking-firefox39: ? → +
tracking-firefox40: ? → +
(Assignee)

Comment 17

3 years ago
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.
(Assignee)

Comment 18

3 years ago
Created attachment 8592854 [details] [diff] [review]
stop disallowing the basic backend.
Attachment #8592854 - Flags: review?(jmuizelaar)
Attachment #8592854 - Flags: review?(jmuizelaar) → review+

Comment 19

3 years ago
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

3 years ago
Created attachment 8592930 [details]
log.txt

Console output when running on 10.6.8 with intel GMA 950

Comment 21

3 years ago
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.
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
(Reporter)

Comment 23

3 years ago
(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

3 years ago
> 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

3 years ago
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
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/nthomas@mozilla.com-f428e02f6acc/try-macosx64/ if anyone wants it).

Comment 28

3 years ago
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.
https://hg.mozilla.org/mozilla-central/rev/c20a7ab389ff
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40

Updated

3 years ago
See Also: bug 1150756
Duplicate of this bug: 1150756
Anthony can you verify the fix on 40? It would be good to verify this works before we try uplifting it to 39.
Flags: needinfo?(anthony.s.hughes)
Flags: qe-verify+
Fixed it for me on 40, OS X 10.9.5

Comment 33

3 years ago
fixed for me :) OS X 10.10.3

Comment 34

3 years ago
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).
(Assignee)

Comment 35

3 years ago
(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

3 years ago
(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.
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?
Flags: needinfo?(nical.bugzilla)
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.
(Assignee)

Comment 39

3 years ago
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]:
Flags: needinfo?(nical.bugzilla)
Attachment #8592854 - Flags: approval-mozilla-aurora?
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+
Attachment #8592854 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Reporter)

Comment 42

3 years ago
I confirm this has been resolved in the latest Firefox 40.0a1 and 39.0a2 builds.
Status: RESOLVED → VERIFIED
status-firefox39: fixed → verified
status-firefox40: fixed → verified
Flags: needinfo?(anthony.s.hughes)
Fabulous. Thanks Anthony.
tracking-firefox39: + → ---
tracking-firefox40: + → ---
You need to log in before you can comment on or make changes to this bug.