1180688 - On OSX 10.10 yosemite VM everything renders as black or white except popups/panels

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[:Gijs (he/him)]

Attachment: Screen Shot 2015-07-06 at 14.43.50.png

Not sure if this is VM-specific or if I can fix it with a VMWare config setting, but I can't work on the frontend when my browser looks like this. This is the latest OSX nightly downloaded from https://nightly.mozilla.org/ less than 20 minutes ago. I tried using safe mode, that made no difference.

Markus, any idea what's going on here?

Comment 1

[Markus Stange [:mstange]]

We're probably attempting to use OMTC BasicCompositor again when HWA can't be enabled for some reason. We should be using main thread BasicLayers instead. We've regressed this before multiple times... it would be nice to know what regressed it this time.

And we should fix OMTC BasicCompositor to work in VMs.

Comment 2

[:Gijs (he/him)]

(fwiw, seems 39 release also breaks...)

Comment 3

[:Gijs (he/him)]

(In reply to Markus Stange [:mstange] from comment #1)
> We're probably attempting to use OMTC BasicCompositor again when HWA can't
> be enabled for some reason. We should be using main thread BasicLayers
> instead. We've regressed this before multiple times... it would be nice to
> know what regressed it this time.

Running mozregression right now.

Comment 4

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8af276ab8636&tochange=37ddc5e2eb72

Maybe the OMTA stuff? Or maybe something else? It looks like I might still get an inbound window, with a bit of luck.

Comment 5

[:Gijs (he/him)]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fba3aaf06f10&tochange=295db120bf12

Comment 6

[:Gijs (he/him)]

nical, could you take a look at this? :-)

Comment 7

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=328609da3d33

Comment 8

[Markus Stange [:mstange]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f6889eeef904

Comment 9

[Markus Stange [:mstange]]

Nical, I read through the patch but couldn't identify the change that could have caused use to fall back to BasicCompositor instead of BasicLayers. If you know how this happened, I think we should fix/revert just that change, and after that we can play on nightly with the change I pushed to try.

Comment 10

[magicp]

FYI, I have same problem.
In my case, with VirtualBox and Guest OS: Snowleopard 10.6.8
I remember timing of this issue...

Firefox Developer Edition 39.0a2 Build 20150423004012 [OK]
Firefox Developer Edition 39.0a2 Build 20150424004008 [NG]

And also Firefox 39.0 is white out now...

Comment 11

[magicp]

Attachment: osx10.6.8-virtualbox.png

Comment 12

[Nicolas Silva [:nical]]

(In reply to Markus Stange [:mstange] from comment #1)
> We're probably attempting to use OMTC BasicCompositor again when HWA can't
> be enabled for some reason. We should be using main thread BasicLayers
> instead. We've regressed this before multiple times... it would be nice to
> know what regressed it this time.
> 
> And we should fix OMTC BasicCompositor to work in VMs.

Disabling OMTC is completely untested, at this point it's just a mine field. I don't think it is a good thing to have users fall back to that configuration ever and I'd much prefer that we fix the basic compositor on mac now.

Comment 13

[:Gijs (he/him)]

(In reply to Nicolas Silva [:nical] from comment #12)
> (In reply to Markus Stange [:mstange] from comment #1)
> > We're probably attempting to use OMTC BasicCompositor again when HWA can't
> > be enabled for some reason. We should be using main thread BasicLayers
> > instead. We've regressed this before multiple times... it would be nice to
> > know what regressed it this time.
> > 
> > And we should fix OMTC BasicCompositor to work in VMs.
> 
> Disabling OMTC is completely untested,

Doesn't safe mode still use this? If so, can we change that (different bug, I suppose)? It sounds like it shouldn't...

Comment 14

[Markus Stange [:mstange]]

(In reply to Nicolas Silva [:nical] from comment #12)
> Disabling OMTC is completely untested, at this point it's just a mine field.

This is just not true. We use BasicLayers for all popups and panels on OS X. And we haven't been using BasicCompositor on OS X at all.

> I don't think it is a good thing to have users fall back to that
> configuration ever and I'd much prefer that we fix the basic compositor on
> mac now.

I completely agree about doing that on mozilla-central, but I disagree that that's the fix we should uplift to 39.

Comment 15

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

[Tracking Requested - why for this release]: Regression in 39.

We know which patch broke this, we'll add that information in here; though it's not clear as to why that patch broke it.  There are some ideas as to how to deal with this complication, but we will first take care of the regression.

Comment 16

[jen strickland :jenstrickland]

Tracked for 40, 41, 42, because of regression, and something we want to fix since users will expect color.

Comment 17

[magicp]

I confirmed the following test on the VirtualBox 4.3.28

1) layers.offmainthreadcomposition.enabled = true -> false

 - Firefox 39.0 [NG -> OK]
 - Firefox Developer Edition 41.0a2 [NG -> OK]
 - Nightly 42.0a1 [NG -> NG]

2) 1) + layers.acceleration.disabled = false -> true

 - Firefox 39.0 [OK -> OK]
 - Firefox Developer Edition 41.0a2 [OK -> OK]
 - Nightly 42.0a1 [NG -> OK]

Comment 18

[magicp]

↑ Guest OS: Mac OS X Snowleopard 10.6.8

Comment 20

[Nicolas Silva [:nical]]

(In reply to Markus Stange [:mstange] from comment #14)
> (In reply to Nicolas Silva [:nical] from comment #12)
> > Disabling OMTC is completely untested, at this point it's just a mine field.
> 
> This is just not true. We use BasicLayers for all popups and panels on OS X.

I did not know that. It's sad.

> And we haven't been using BasicCompositor on OS X at all.

We do use it on other platforms. It gets a lot more testing coverage than BasicLayerManager.

> I completely agree about doing that on mozilla-central, but I disagree that
> that's the fix we should uplift to 39.

I didn't expect that presenting a frame off the main thread without opengl would be as complicated as it turns out to be on Mac. But yeah, agreed, I don't want to uplift a complex solution either.

Comment 21

[Nicolas Silva [:nical]]

Attachment: no BasicCompositor for you MacOSX!

This should do for now.

Comment 22

[Nicolas Silva [:nical]]

There will be a build with the patch applied here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=612758d7e461

Jeff, you told me you have an environment that reproduces this, could you verify that this build fixes the issue?

Comment 23

[Nicolas Silva [:nical]]

Attachment: no BasicCompositor for you MacOSX!

forgot to qrefresh before submitting the previous patch, sorry.

Comment 25

[Nicolas Silva [:nical]]

> 
> forgot to qrefresh before submitting the previous patch, sorry.

... and the build is here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d842d9c71d05

Comment 26

[Markus Stange [:mstange]]

Comment on attachment 8630925 [details] [diff] [review]
no BasicCompositor for you MacOSX!

Review of attachment 8630925 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! This certainly seems like the least risky approach. And sorry about the sadness.

Comment 27

[:Gijs (he/him)]

(In reply to Nicolas Silva [:nical] from comment #25)
> > 
> > forgot to qrefresh before submitting the previous patch, sorry.
> 
> ... and the build is here:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=d842d9c71d05

This seems to still be broken for me.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

(In reply to :Gijs Kruitbosch from comment #27)
> (In reply to Nicolas Silva [:nical] from comment #25)
> > > 
> > > forgot to qrefresh before submitting the previous patch, sorry.
> > 
> > ... and the build is here:
> > https://treeherder.mozilla.org/#/jobs?repo=try&revision=d842d9c71d05
> 
> This seems to still be broken for me.

This works for me in a 10.6 VM. Are you sure it's still broken?

Comment 29

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/89d664f5f70f

Comment 30

[Nicolas Silva [:nical]]

Comment on attachment 8630925 [details] [diff] [review]
no BasicCompositor for you MacOSX!

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Firefox is unusable if the host OS is Mac in a VM
[Describe test coverage new/current, TreeHerder]: None.
[Risks and why]: very low, we just make sure to avoid a configuration that is known to be broken.
[String/UUID change made/needed]:

Comment 31

[:Gijs (he/him)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #28)
> (In reply to :Gijs Kruitbosch from comment #27)
> > (In reply to Nicolas Silva [:nical] from comment #25)
> > > > 
> > > > forgot to qrefresh before submitting the previous patch, sorry.
> > > 
> > > ... and the build is here:
> > > https://treeherder.mozilla.org/#/jobs?repo=try&revision=d842d9c71d05
> > 
> > This seems to still be broken for me.
> 
> This works for me in a 10.6 VM. Are you sure it's still broken?

I just redownloaded the new trybuild, and it's still broken for me on my 10.10 VM (on a 10.9 host, vmware fusion 7.1.2).

Comment 32

[Nicolas Silva [:nical]]

looks like we are dealing with 2 issues? This bug doesn't have too many comments yet so let's keep investigating here.

Comment 33

[Nicolas Silva [:nical]]

Gijs, I spinned another build with some logging to understand in what configuration the browser ends up in your case when setting OMTC and the compositor backends up here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8d7bc271e43

Could you run it and forward me the standard output? I prefixed all of the extra logging with "[nical]" to help with grepping for the relevant parts.

Thanks!

Comment 34

[:Gijs (he/him)]

(In reply to Nicolas Silva [:nical] from comment #33)
> Gijs, I spinned another build with some logging to understand in what
> configuration the browser ends up in your case when setting OMTC and the
> compositor backends up here:
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8d7bc271e43
> 
> Could you run it and forward me the standard output? I prefixed all of the
> extra logging with "[nical]" to help with grepping for the relevant parts.
> 
> Thanks!

Gijss-Mac:Desktop gijs$ Nightly.app/Contents/MacOS/firefox -P trunk
[nical] Attempting to create an OpenGL compositor
[nical] Failed to initialise the compositor
[nical] Failed to set OMTC up

(profile manager, it turns out I don't have a profile called "trunk" on this VM; but I can't see the list, so I'mma just hit enter and have it start whatever I do have)

Gijss-Mac:Desktop gijs$ 
Gijss-Mac:Desktop gijs$ [nical] Attempting to create an OpenGL compositor
[nical] Failed to initialise the compositor
[nical] Failed to set OMTC up
[nical] Attempting to create an OpenGL compositor
[nical] Failed to initialise the compositor
[nical] Failed to set OMTC up



(This last chunk is all one run; I assume it's giving info once for the main window and once for the e10s'ified content window, or something?)

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/89d664f5f70f

Comment 36

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

(In reply to Nicolas Silva [:nical] from comment #30)
> [Risks and why]: very low, we just make sure to avoid a configuration that
> is known to be broken.

Does this negatively impact the standard OSX config (i.e. MacBook Air/Pro)?

Comment 37

[Nicolas Silva [:nical]]

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #36)
> (In reply to Nicolas Silva [:nical] from comment #30)
> > [Risks and why]: very low, we just make sure to avoid a configuration that
> > is known to be broken.
> 
> Does this negatively impact the standard OSX config (i.e. MacBook Air/Pro)?

No, these always enjoy a nice hardware accelerated compositor backend, which works well unless mac runs in a VM.

Comment 38

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

Even in the safe mode?  Or, more to the point, any changes to the safe mode, or when the users turn off "use hardware acceleration when available"?

Comment 39

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] from comment #38)
> Even in the safe mode?  Or, more to the point, any changes to the safe mode,
> or when the users turn off "use hardware acceleration when available"?

Good question. For those, If I understood correctly, before the patch they will have a BasicCompositor that uses opengl to present the frame, and after the patch they will have a non-OMTC BasicLayerManager.

this new configuration is not very well tested so I would say it is a negative impact for users who change the pref. So perhaps it would be better to somehow detect that we are in a VM instead of disabling BasicCompositor for all mac users, Jeff do you know how to do that?

Comment 40

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

Yes, that's what I thought.  We can't mess with the safe mode.  It's supposed to be safe.  I would much rather mess with VMs than the safe mode, and this includes nightly as well.  We should back this out until we figure out the right thing, and revisit the solution to bug 1125848.

Comment 41

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nicolas Silva [:nical] from comment #39)
> (In reply to Milan Sreckovic [:milan] from comment #38)
> > Even in the safe mode?  Or, more to the point, any changes to the safe mode,
> > or when the users turn off "use hardware acceleration when available"?
> 
> Good question. For those, If I understood correctly, before the patch they
> will have a BasicCompositor that uses opengl to present the frame, and after
> the patch they will have a non-OMTC BasicLayerManager.
> 
> this new configuration is not very well tested so I would say it is a
> negative impact for users who change the pref. So perhaps it would be better
> to somehow detect that we are in a VM instead of disabling BasicCompositor
> for all mac users, Jeff do you know how to do that?

Sorry, why do we need to detect VM now and we didn't need to before?

Comment 42

[Nicolas Silva [:nical]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #41)
> 
> Sorry, why do we need to detect VM now and we didn't need to before?

Before we were in a situation where things worked out by luck rather than from handling the problematic case explicitly. A patch that wasn't supposed to have an impact on this stuff apparently broke that fragile equilibrium and it is not even obvious how. If BasicCompositor is broken on mac-inside-a-VM, i'd rather have code that explicitly handles it, than get back to something that will potentially break an untested platform (that we apparently care about) every time we touch this area of the code. I (naively) assume that detecting that we are in a VM is something that isn't too risky and that we can uplift all the way to beta without breaking a sweat. Long term I would rather have BasicCompositor always work, even in the most broken platforms.

Comment 43

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nicolas Silva [:nical] from comment #42)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #41)
> > 
> > Sorry, why do we need to detect VM now and we didn't need to before?
> 
> Before we were in a situation where things worked out by luck rather than
> from handling the problematic case explicitly. A patch that wasn't supposed
> to have an impact on this stuff apparently broke that fragile equilibrium
> and it is not even obvious how. If BasicCompositor is broken on
> mac-inside-a-VM, i'd rather have code that explicitly handles it, than get
> back to something that will potentially break an untested platform (that we
> apparently care about) every time we touch this area of the code. I
> (naively) assume that detecting that we are in a VM is something that isn't
> too risky and that we can uplift all the way to beta without breaking a
> sweat. Long term I would rather have BasicCompositor always work, even in
> the most broken platforms.

Can't you just detect the situation by observing accelerated gl context creation failing then?

Comment 44

[Nicolas Silva [:nical]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #43)
> 
> Can't you just detect the situation by observing accelerated gl context
> creation failing then?

I don't know, Maybe? You tell me, you know more about that stuff than I do. I thought we were in a hurry to get a safe fix and uplift it. If we are not, I can spend some time to get a mac with an extra osx license to run in the vm, set things up and figure that out.

Comment 45

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nicolas Silva [:nical] from comment #44)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #43)
> > 
> > Can't you just detect the situation by observing accelerated gl context
> > creation failing then?
> 
> I don't know, Maybe? You tell me, you know more about that stuff than I do.
> I thought we were in a hurry to get a safe fix and uplift it. If we are not,
> I can spend some time to get a mac with an extra osx license to run in the
> vm, set things up and figure that out.

Sorry. I meant to imply that the thing that is different in VMs is that accelerated gl context creation fails. That should be all the detection that you need.

Comment 46

[Kate Glazko]

Comment on attachment 8630925 [details] [diff] [review]
no BasicCompositor for you MacOSX!

Very low risk, making sure to avoid a configuration that is known to be broken.

Comment 47

[Kate Glazko]

Nical, do you want to continue the discussion about VM support in a new bug?

Comment 48

[Nicolas Silva [:nical]]

Comment on attachment 8630925 [details] [diff] [review]
no BasicCompositor for you MacOSX!

Sorry, I should have removed the flags earlier. We would like to not take the risk of regressing safe mode for mac users (that are not in a vm). And this patch makes safe mode go into non-OMTC which is not well tested so could have regressions.
I am looking into an alternative solution, and if it turns out to be too risky we can reconsider this one.

Comment 49

[Nicolas Silva [:nical]]

Attachment: Fail to initialize the BasicCompositor if GLPresenter fails on mac.

Comment 50

[Markus Stange [:mstange]]

Comment on attachment 8632757 [details] [diff] [review]
Fail to initialize the BasicCompositor if GLPresenter fails on mac.

Review of attachment 8632757 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/cocoa/nsChildView.mm
@@ +2610,5 @@
> +nsChildView::InitCompositor(Compositor* aCompositor)
> +{
> +  if (aCompositor->GetBackendType() == LayersBackend::LAYERS_BASIC) {
> +    if (!mGLPresenter) {
> +      mGLPresenter = GLPresenter::CreateForWindow(this);

Should we remove the existing call of GLPresenter::CreateForWindow in nsChildView::StartRemoteDrawing()? We could replace it with an assert, if that's not too risky to uplift.

Comment 51

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bee2c9b57a80
https://hg.mozilla.org/integration/mozilla-inbound/rev/a03299ecdf82

Comment 52

[Nicolas Silva [:nical]]

I added an assertion (without removing the CreateForWindow call for now to be extra safe with the uplift), backed the first fix out and landed on inbound. Let's see how it goes.

Comment 53

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

https://hg.mozilla.org/mozilla-central/rev/bee2c9b57a80
https://hg.mozilla.org/mozilla-central/rev/a03299ecdf82

Comment 54

[Nicolas Silva [:nical]]

Hey Jeff, could you check again that nightly still works in the VM? thanks!

Comment 55

[Jeff Muizelaar [:jrmuizel]]

Nightly is white for me.

Comment 56

[Nicolas Silva [:nical]]

Attachment: make sure that a bunch of widget states are nulled if creating a compositor failed

The reason the second patch did not work is that when the compositor creation, we still left the widget with references to some of the omtc object, even though they were not initialized. This patch makes sure we null these out and fixes the problem for me.

It would make more sense to null out the references in DestroyCompositor, but there is something tricky around this part when shutting down, related to some code running at shutdown potentially causing the re-creating of a layer manager, compositor, etc during the middle of shutdown, and I am not 100% certain how nulling out the refs in DestroyCompositor would affect this in the case of shutdown.
So for now it is safer to only null them out if the creation of the compositor failed. Once we have uplifted the patch we can take the time to look into moving that into DestroyCompositor and see if it breaks something.

Comment 57

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

On that last comment - let's open another bug for the problem above, perhaps add a "do not recreate, being destroyed" flag to properly fix this problem.  Don't like tricky and unknown things :)

Comment 58

[Pulsebot]

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

Comment 59

[Carsten Book [:Tomcat]]

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

Comment 60

[Nicolas Silva [:nical]]

Attachment: Patch rebased on top of aurora (carrying r=mstange)

This patch folds the two patches that landed and applies cleanly on top of aurora.

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Firefox is unusable in if the host os is mac in a vm.
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: low risk, affects very few users which are in completely broken state before the patch.
[String/UUID change made/needed]:

Comment 61

[Nicolas Silva [:nical]]

Attachment: Patch rebased on top of beta (carrying r=mstange)

This patch folds the two patches that landed and applies cleanly on top of beta.

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Firefox unusable if the host os is mac in a vm
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: low, affect few users which are already in a broken state without the patch. 
[String/UUID change made/needed]:

Comment 62

[Stefan]

I am seeing partially or totally black pages on resizing windows on pre-Yosemite Mac OS 10.8.5 starting in FF 39. 
http://www.zweigmedia.com/FirefoxBlackPage.png
Not sure if this is related.

Comment 63

[Markus Stange [:mstange]]

(In reply to Stefan from comment #62)
> I am seeing partially or totally black pages on resizing windows on
> pre-Yosemite Mac OS 10.8.5 starting in FF 39. 
> http://www.zweigmedia.com/FirefoxBlackPage.png
> Not sure if this is related.

This looks similar to what I was seeing when I tried using CompositorOGL with a non-accelerated GLContext in a VM. But Firefox 39 shouldn't be able to get into that state - we currently refuse creating non-accelerated GLContexts on Mac. So you shouldn't be able to get into that state... this is very confusing.

Comment 64

[magicp]

See Also: Bug 1185321

Comment 65

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

magicp, could you please verify the fix works for you in 7/21 nightly build? Thanks!

Comment 66

[magicp]

(In reply to Ritu Kothari (:ritu) from comment #65)
> magicp, could you please verify the fix works for you in 7/21 nightly build?
> Thanks!

It works fine when multi-process is disabled. But, in case of multi-process as follows...

Case #1
layers.offmainthreadcomposition.enabled = true
layers.acceleration.disabled = false
- XUL documents      [OK]
- HTML documents     [NG] Please find the attached image "test case 1-2.png"

Case #2
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = false
- XUL documents      [OK]
- HTML documents     [NG]

Case #3
layers.offmainthreadcomposition.enabled = false
layers.acceleration.disabled = true
- XUL documents      [OK]
- HTML documents     [OK]

My environment:
- Nightly 42.0a1 (20150721030212) and later
- Mac OS X 10.6.8 (Guest OS) in VirtualBox 4.3.30

Comment 67

[magicp]

Attachment: test case 1-2.png

Comment 68

[Nicolas Silva [:nical]]

If anything gets rendered at all then the issues that are left are different bugs, let's file new bugs for them.

Comment 69

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

Comment on attachment 8636620 [details] [diff] [review]
Patch rebased on top of beta (carrying r=mstange)

Although there are still failures with e10s, e10s is disabled by default in 40 and 41 and, as Nical said, we should file follow up bugs. Beta+

Comment 70

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

Comment on attachment 8636618 [details] [diff] [review]
Patch rebased on top of aurora (carrying r=mstange)

Aurora+

Comment 71

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0956814d7faf

Comment 72

[Ryan VanderMeulen [:RyanVM]]

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

Comment 73

[Kamil Jozwiak [:kjozwiak]]

magicp, would you mind creating a follow up bug relating to the e10s issues?

Comment 74

[magicp]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #73)
> magicp, would you mind creating a follow up bug relating to the e10s issues?

I have filed Bug 1187322. Please follow up.

Comment 75

[noitidart]

(In reply to magicp from comment #17)
> I confirmed the following test on the VirtualBox 4.3.28
> 
> 1) layers.offmainthreadcomposition.enabled = true -> false
> 
>  - Firefox 39.0 [NG -> OK]
>  - Firefox Developer Edition 41.0a2 [NG -> OK]
>  - Nightly 42.0a1 [NG -> NG]
> 
> 2) 1) + layers.acceleration.disabled = false -> true
> 
>  - Firefox 39.0 [OK -> OK]
>  - Firefox Developer Edition 41.0a2 [OK -> OK]
>  - Nightly 42.0a1 [NG -> OK]

Confirmed that setting these prefs to false and true respectively fixed it! Thank you so much!!

Comment 76

[noitidart]

In case anyone has to blindly run the code and cant view the preferences. Hit Ctrl Shift J to open borwser console (hopefully your dev prefs are enabled). paste and hit enter the nrestart:

Services.prefs.setBoolPref('layers.offmainthreadcomposition.enabled', false); Services.prefs.setBoolPref('layers.acceleration.disabled', true);

Comment 77

[noitidart]

Just confirming that this was fixed in nightly. And also a side bug even after setting those prefs in my previous reply in order to make it work inFF39. So in FF39 even with those prefs set, things would work, however nsIAlertService would not show any alerts visually, although the alertshow notification triggered, so meaning it was just visual. so doing

    Cc['@mozilla.org/alerts-service;1'].getService(Ci.nsIAlertsService).showAlertNotification(null, 'title', 'msg');


would not work.

I downloaded nightly and alert service is working. profile manager is showing properly now too. real cool thanks for the fix all!