Closed Bug 974007 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: Graphics, defect)

30 Branch
x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30
Tracking Status
firefox30 - ---

People

(Reporter: aris-addons, Assigned: billm)

References

Details

(Keywords: regression)

Attachments

(3 files)

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.
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.
So it seems glitch only affects virtual machines.
Huh, that's odd. Brandon, are you also running OS X in a VM?
Flags: needinfo?(bcheng.gt)
OS: Windows 7 → Mac OS X
Blocks: 893661
I'm not running it in VM, but non-native hardware. The issue appeared on the 2/13 central builds. 2/12 is fine.
Flags: needinfo?(bcheng.gt)
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bgirard)
Flags: needinfo?(aris-t2)
I could be, can you verify if anything is getting printed to the console?
Flags: needinfo?(bgirard)
tinderbox-builds/mozilla-central-macosx64/1392212048/
--> works fine

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

tinderbox-builds/mozilla-central-macosx64/1392238119/
--> broken
Flags: needinfo?(aris-t2)
(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...
(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
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.
Blocking because this results in a broken build for users.

Can anyone confirm that this probably isn't on the aurora channel?
Component: Untriaged → Graphics
Product: Firefox → Core
(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.
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
Flags: needinfo?(wmccloskey)
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.
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.
Flags: needinfo?(wmccloskey)
Attached patch remote-tabs-fxSplinter Review
See comment 16.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Attachment #8379129 - Flags: review?(felipc)
Attachment #8379129 - Flags: review?(felipc) → review+
Attachment #8379131 - Flags: review?(matt.woodrow) → review+
Duplicate of this bug: 975251
https://hg.mozilla.org/mozilla-central/rev/59a30471542b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Benoit, Does this work for you if so I don't think we will need tracking?
Flags: needinfo?(bgirard)
(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.
Flags: needinfo?(bgirard)
Bug is fixed for me. 
Thanks.
Duplicate of this bug: 973523
You need to log in before you can comment on or make changes to this bug.