Nightly only shows a plain white/grey window on OS X in a VM

RESOLVED FIXED in Firefox 34

Status

()

Core
Widget: Cocoa
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: Gijs, Assigned: nical)

Tracking

({regression})

Trunk
mozilla35
All
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox32 unaffected, firefox33 unaffected, firefox34+ fixed, firefox35 fixed)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Starting today's nightly from the commandline shows:

Gijss-Mac:~ gijs$ /Applications/FirefoxNightly.app/Contents/MacOS/firefox
ERROR: Changing compositor from 2 to 1.

Trying to find a regression window at the moment.
(Reporter)

Comment 1

3 years ago
m-c: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d697d649c765&tochange=eed9fe35a00d

Still looking at inbound.
(Reporter)

Comment 2

3 years ago
(this is on beta 1, btw... I'll update to beta 2 after I figure out this regression window; maybe that'll fix it? It'd somewhat surprise me because the m-c regression window seems to not include any yosemite-specific stuff, apart from my frontend patch for the urlbar/searchbar styling, and that shouldn't be able to cause this...)
(Reporter)

Comment 3

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d697d649c765&tochange=de5cefa8e52e

which is very strange because this is still huge (although bug 1028288 jumps out at me). Poking mozregression some more to see if I can't narrow this down without resorting to building...
(Reporter)

Comment 4

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0cba3e5a377d&tochange=ab4ef3fa85bd

And looking at that patch, this makes some amount of sense, as the code removed was also run on mac, and not just Linux as the patch description said... Nical, can you have a look?
Blocks: 994541
Flags: needinfo?(nical.bugzilla)
Keywords: regressionwindow-wanted
(Reporter)

Comment 5

3 years ago
See bug 974007 comment 14, I think? Might be broken on other OS Xs in VMs as well, but I don't have any so can't test. Looks like nobody ever figured out why the basic compositor is broken on OS X.
Summary: After a recent update OS X nightlies produce a white/grey window with no content on 10.10 VM → [10.10] Nightly only shows a plain white/grey window on OS X Yosemite VM
(In reply to :Gijs Kruitbosch from comment #0)
> Starting today's nightly from the commandline shows:
> 
> Gijss-Mac:~ gijs$ /Applications/FirefoxNightly.app/Contents/MacOS/firefox
> ERROR: Changing compositor from 2 to 1.

2 is LAYERS_OPENGL and 1 is LAYERS_BASIC.

I wonder what triggers the change to BasicCompositor.

Gijs, did you get OpenGL compositing in your VM prior to this change, or did it fall back to BasicLayers?
(Reporter)

Comment 7

3 years ago
(In reply to Markus Stange [:mstange] from comment #6)
> (In reply to :Gijs Kruitbosch from comment #0)
> > Starting today's nightly from the commandline shows:
> > 
> > Gijss-Mac:~ gijs$ /Applications/FirefoxNightly.app/Contents/MacOS/firefox
> > ERROR: Changing compositor from 2 to 1.
> 
> 2 is LAYERS_OPENGL and 1 is LAYERS_BASIC.
> 
> I wonder what triggers the change to BasicCompositor.
> 
> Gijs, did you get OpenGL compositing in your VM prior to this change, or did
> it fall back to BasicLayers?

I don't know - how would I check?
(Reporter)

Comment 8

3 years ago
Here's the about:support output from the VM:

Device ID	0x 405
GPU Accelerated Windows	0/1 Basic
Vendor ID	0x15ad
windowLayerManagerRemote	false
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

so yes, this was using basic before...

Comment 9

3 years ago
I filed bug 1060948 yesterday, but even though the symptoms looks quite similar I guess it must be a different issue?
(Assignee)

Comment 10

3 years ago
I'll submit a fix tomorrow.
(Assignee)

Comment 11

3 years ago
Created attachment 8482627 [details] [diff] [review]
Restore the previous behavior (disabling basic OMTC) except on Linux
Assignee: nobody → nical.bugzilla
Attachment #8482627 - Flags: review?(matt.woodrow)
Flags: needinfo?(nical.bugzilla)
(Reporter)

Comment 12

3 years ago
(In reply to Stefan [:stefanh] from comment #9)
> I filed bug 1060948 yesterday, but even though the symptoms looks quite
> similar I guess it must be a different issue?

It looks different to me, yes - but you identified a regressing cset, which might be the same? I can't tell, see the needinfo in that bug. :-)
Nical, can you describe what went wrong and why Linux and OS X need different behavior?
(Assignee)

Comment 14

3 years ago
(In reply to Markus Stange [:mstange] from comment #13)
> Nical, can you describe what went wrong and why Linux and OS X need
> different behavior?

I don't know what's wrong with basic OMTC on mac. I'll have to look into it and ask around. In the mean time reverting the change that caused people to use basic OMTC on mac lets me focus on the higher priority items for now.
needinfo'ing myself as a remainder for later.
Flags: needinfo?(nical.bugzilla)
Basic OMTC on Mac is working on my machine. However, it works by creating an OpenGL context and doing very basic operations on it (see GLPresenter in nsChildView.mm). If OpenGL context creation fails on some machines we'll need to think of a different solution. (It probably means that we need to snapshot the composition result, ship it back to the main thread, and only update the window on the main thread.)
Are we planning to use OMTC always for all drawing?
Attachment #8482627 - Flags: review?(matt.woodrow) → review+
(In reply to Markus Stange [:mstange] from comment #15)
> Are we planning to use OMTC always for all drawing?

Yeah, that was the plan.
(In reply to Markus Stange [:mstange] from comment #15)
> Basic OMTC on Mac is working on my machine. However, it works by creating an
> OpenGL context and doing very basic operations on it (see GLPresenter in
> nsChildView.mm). If OpenGL context creation fails on some machines we'll
> need to think of a different solution. (It probably means that we need to
> snapshot the composition result, ship it back to the main thread, and only
> update the window on the main thread.)

Not to derail this, but is that always the case? TenFourFox blocks acceleration at the OS level, though we probably do create a GL context (I say probably -- GLContextProviderCGL::CreateForWindow likely succeeds on 10.4, I have to check). Nevertheless, OMTC does work for us.

Updated

3 years ago
Duplicate of this bug: 1060948
(Assignee)

Comment 19

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/177fdd6bfb19
(Assignee)

Comment 20

3 years ago
WError fix https://hg.mozilla.org/integration/mozilla-inbound/rev/51d39a24b168
Flags: needinfo?(nical.bugzilla)
https://hg.mozilla.org/mozilla-central/rev/177fdd6bfb19
https://hg.mozilla.org/mozilla-central/rev/51d39a24b168
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
This is still unfixed on Aurora.

[Tracking Requested - why for this release]: bad regression for users that don't get OpenGL (e.g. VMs)
No longer blocks: 1040250
status-firefox32: --- → unaffected
status-firefox33: --- → unaffected
status-firefox34: --- → affected
status-firefox35: --- → fixed
tracking-firefox34: --- → ?
Summary: [10.10] Nightly only shows a plain white/grey window on OS X Yosemite VM → Nightly only shows a plain white/grey window on OS X in a VM
Duplicate of this bug: 1069763
Comment 2 said that this was an issue on 33 beta1, which is the current beta cycle. Is 33 affected?

nical - Can you pleas submit an Aurora approval request so that we can fix this in 34?
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(gijskruitbosch+bugs)
status-firefox33: unaffected → ?
tracking-firefox33: --- → ?
tracking-firefox34: ? → +
The word "beta" in comment 2 was referring to the Mac OS 10.10 Beta, not the Firefox Beta.
(Assignee)

Comment 26

3 years ago
(In reply to Markus Stange [:mstange] from comment #25)
> The word "beta" in comment 2 was referring to the Mac OS 10.10 Beta, not the
> Firefox Beta.

Yes, the regression and the fix where on the same train.
Flags: needinfo?(nical.bugzilla)
My mistake. Thank you for clarifying. 

nical - I'm still interested in uplifting the fix to Aurora. Reminder to please submit an approval request.
status-firefox33: ? → unaffected
tracking-firefox33: ? → ---
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(nical.bugzilla)
(Assignee)

Comment 28

3 years ago
Comment on attachment 8482627 [details] [diff] [review]
Restore the previous behavior (disabling basic OMTC) except on Linux

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Crashes on Mac
[Describe test coverage new/current, TBPL]:
[Risks and why]: not risky, restores code that has been used for a long while, has been baking on m-c for a while.
[String/UUID change made/needed]:
Attachment #8482627 - Flags: approval-mozilla-aurora?
Flags: needinfo?(nical.bugzilla)
Comment on attachment 8482627 [details] [diff] [review]
Restore the previous behavior (disabling basic OMTC) except on Linux

Aurora+
Attachment #8482627 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Comment 30

3 years ago
Created attachment 8493924 [details] [diff] [review]
upliftable patch (carries r=mattwoodrow)

This contains the above patch folded with the WError fix and applies on aurora
https://hg.mozilla.org/releases/mozilla-aurora/rev/0ca144377622
status-firefox34: affected → fixed
You need to log in before you can comment on or make changes to this bug.