974007 - Nightly builds do not work on MacOSX anymore - blank white screen on all browser windows

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Aris]

Attachment: nightly-blank-window.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140213172947

Steps to reproduce:

Installed latest Firefox nightly update on OSX 10.9.x and 10.8.x systems running in VMware and VirtualBox. The problem exist since Nightly build 2014-02-13. All nightly builds after 2014-02-12 have this problem.

Build 2014-02-13 was the last one, which worked fine.


Actual results:

After the update every Firefox window is only just blank white. Tested with and without hardware acceleration in Firefox.
Tested with and without graphics acceleration in VM/OS settings.


Expected results:

Firefox window(s) should be displayed correctly.
This only happens with nightly builds. Aurora works fine for now.

Comment 1

[RobertJ]

I'm running nightly 2014-02-18 on OSX 10.9.1 with no issues. I have seen no issues with any of the Nightly's over the last few weeks.

I also have the Nightly running on my wife's MacBook Pro with no issue.

Comment 2

[Aris]

So it seems glitch only affects virtual machines.

Comment 3

[:Gijs (out for now; he/him)]

Huh, that's odd. Brandon, are you also running OS X in a VM?

Comment 4

[Brandon Cheng]

I'm not running it in VM, but non-native hardware. The issue appeared on the 2/13 central builds. 2/12 is fine.

Comment 5

[:Gijs (out for now; he/him)]

Let's call this confirmed based on multiple reports with the same regression window:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=802d87c77e76&tochange=a62bde1d6efe

Looking at that window, nothing immediately jumps out. I'd suspect the inbound merges more than anything else, so it'd probably be helpful if people affected by this issue could test builds from here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64/1392212048/
( https://tbpl.mozilla.org/?rev=c11bd46b6a2a )

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64/1392213789/
( https://tbpl.mozilla.org/?rev=879038dcacb7 )

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64/1392238119/
( https://tbpl.mozilla.org/?rev=18e7634d4094 )

to narrow that range down a bit further...

Hmm, unless it's bug 971154? Benoit, is that plausible at all?

Comment 6

[Benoit Girard (:BenWa)]

I could be, can you verify if anything is getting printed to the console?

Comment 7

[Aris]

tinderbox-builds/mozilla-central-macosx64/1392212048/
--> works fine

tinderbox-builds/mozilla-central-macosx64/1392213789/
--> broken

tinderbox-builds/mozilla-central-macosx64/1392238119/
--> broken

Comment 8

[:Gijs (out for now; he/him)]

(In reply to Aris from comment #7)
> tinderbox-builds/mozilla-central-macosx64/1392212048/
> --> works fine
> 
> tinderbox-builds/mozilla-central-macosx64/1392213789/
> --> broken
> 
> tinderbox-builds/mozilla-central-macosx64/1392238119/
> --> broken

Well, that excludes bug 971154, at least. Sorry, Benoit!

New regression window:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c11bd46b6a2a&tochange=879038dcacb7

Wonder if this was caused by OMTC...

Comment 9

[Brandon Cheng]

(In reply to Benoit Girard (:BenWa) from comment #6)
> I could be, can you verify if anything is getting printed to the console?

I get the following two lines multiple times repeatedly (and nonstop). I can provide a screenshot later in the day.

invalid pixel context
invalid format

Comment 10

[Eric K.]

I've been experiencing the same problem running Nightly on my Mac Mini running OS X 10.7.5

The windows are a solid white except for the red, yellow and green buttons on the upper right.

I get: "ERROR: Changing compositor from 2 to 1." when I launch it from the command line.

Comment 11

[Benoit Girard (:BenWa)]

Blocking because this results in a broken build for users.

Can anyone confirm that this probably isn't on the aurora channel?

Comment 12

[Aris]

(In reply to Benoit Girard (:BenWa) from comment #11)
> Blocking because this results in a broken build for users.
> 
> Can anyone confirm that this probably isn't on the aurora channel?

Yes, this only happens on nightly and not on aurora channel.

Comment 13

[Matt Woodrow (:mattwoodrow)]

I suspect bug 960783.

Comment 14

[Matt Woodrow (:mattwoodrow)]

Ok, so I think the problem here is that we're now using the BasicCompositor on OSX when we fail to initialize CompositorOGL. Previously we instead fell back to main-thread compositing.

The code at [1] is meant to stop this from happening unless e10s is enabled. But it's checking browser.tabs.remote which is always true now, and we instead want to check if this window has e10s enabled.

Looks like some of the patches from bug 960783 haven't landed yet, including the one that I reviewed. Once those land we should have 'mUseOffMainThreadCompositing' as a member in nsBaseWidget, and we can check that instead of BrowserTabsRemote(). 'mUsesRemoteTabs' or something might be a nice name given the new usage.

Fixing that should take us back to where we were. I don't have any explanations for why the BasicCompositor is broken on OSX, that needs a separate investigation.

Bill, is there any reason those patches haven't landed?



[1] http://mxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsBaseWidget.cpp#946

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Bill is sick today and likely tomorrow as well - if there's an urgent fix needed please just land the patches before for him if they look good.

Comment 16

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The reason I didn't land the graphics patch in 960783 is that it was causing failures where we assumed that the existence of a compositing thread implied that we should use compositing (or, relatedly, the existence of an image bridge thread meant we should use async video). I wonder how this affects people on MacOS with blacklisted video cards?

Anyway, I took that patch and made it more conservative:

1. browser.tabs.remote no longer forces OMTC to be on.
2. browser.tabs.remote.autostart does force-enable OMTC.
3. When you ask for a new e10s window, we check if the OMTC pref is set. If it's not, we ask you to set it and just give you a normal window.
4. We allow the basic compositor only in e10s windows (or if you set the force-basic pref).

One nice thing about these patches is that we can turn on the e10s menu option on all platforms now. Most people will just see an alert asking them to enable OMTC, but I think that's better than what we have now.

Comment 17

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: remote-tabs-fx

See comment 16.

Comment 18

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: remote-tabs-gfx

See comment 16.

Comment 19

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/59a30471542b

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/59a30471542b

Comment 22

[Benjamin Kerensa [:bkerensa]]

Benoit, Does this work for you if so I don't think we will need tracking?

Comment 23

[Benoit Girard (:BenWa)]

(In reply to Benjamin Kerensa [:bkerensa] from comment #22)
> Benoit, Does this work for you if so I don't think we will need tracking?

I could never reproduce the bug. Perhaps someone else can verify.

Comment 24

[Aris]

Bug is fixed for me. 
Thanks.