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.
Keywords: regression, regressionwindow-wanted
Tinderbox regression window =========================== Last Good: 20150325130909 [f40ee067d081] First Bad: 20150325165811 [37d3dcbf23a9] https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40ee067d081&tochange=37d3dcbf23a9
status-firefox39: unaffected → affected
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.
(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.
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).
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.
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.
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 firstname.lastname@example.org explaining these concerns so you can get insight directly from the people writing the code.
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?
So, it looks like the third (not uplifted) patch to bug 1125848 broke the basic layers on OS X.
(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
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.
Tracking for 39+.
tracking-firefox39: ? → +
tracking-firefox40: ? → +
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.
Created attachment 8592854 [details] [diff] [review] stop disallowing the basic backend.
Attachment #8592854 - Flags: review?(jmuizelaar)
Attachment #8592854 - Flags: review?(jmuizelaar) → review+
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
Created attachment 8592930 [details] log.txt Console output when running on 10.6.8 with intel GMA 950
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
(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.
> 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.
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://email@example.com/try-macosx64/ if anyone wants it).
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
Anthony can you verify the fix on 40? It would be good to verify this works before we try uplifting it to 39.
Fixed it for me on 40, OS X 10.9.5
fixed for me :) OS X 10.10.3
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).
(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.
(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?
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 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]:
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+
status-firefox39: affected → fixed
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
Fabulous. Thanks Anthony.
tracking-firefox39: + → ---
tracking-firefox40: + → ---
You need to log in before you can comment on or make changes to this bug.