[GitHub issue by autonome on 2012-07-24T00:01:21Z, https://github.com/mozilla-b2g/gaia/issues/2738] saw a couple of people pull a fresh clone and run into this. here are the errors from the js console: Timestamp: 7/23/12 4:47:39 PM Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIServerSocket.init] Source File: chrome://browser/content/shell.js Line: 353 Timestamp: 7/23/12 4:47:40 PM Error: TypeError: CustomEventManager is undefined Source File: chrome://browser/content/shell.js Line: 145

[GitHub comment by autonome on 2012-07-24T00:05:05Z] @caseyyee said it was a conflict with Crashplan, which uses the same port as some b2g service.

Is this resolved?

I'm not sure if this is the same issue, but I think I'm seeing this when I run a gecko 18-based desktop build from http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-beta/. The error I get is: Timestamp: 11/26/2012 10:44:47 PM Error: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXPCComponents_Utils.import] Source File: file:///home/stas/Desktop/b/b2g18/components/HealthReportService.js Line: 10 Running the build with the same profile gets rid of the white screen Gecko 19-based desktop build from http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/ works fine.

(In reply to Staś Małolepszy :stas (traveling) from comment #3) > Gecko 19-based desktop build from > http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/ > works fine. Correction: 19 works fine, but 20 (central) has the same HealthReportService.js error as 18.

I just tried Linux desktop builds with m-c (Firefox 20) and beta (18), and the latest gaia repo, and I get the white screen too. I see the same error about HealthReportService.js. I'm attaching the full stdout/err in case there's anything else useful in there.

I'm able to reproduce on inbound. Disabling GL and omtc makes it go away.

With a vanilla build, I can only reproduce intermittently. This looks like some kind of race condition triggered by FTU.

When I see the white screen, if I randomly click around the bottom-right of the screen, I can see FTU processing input events. This allows me to click through FTU. After I get through, I still see the white screen though. Restarting b2g after that makes the bug go away reliably.

Reliable STR, with VARIANT=user configuration $ $b2g/build.sh $b2g/gaia $ [run b2g desktop build] Bug 814583 doesn't fix this. Looks like some kind of race condition. Workaround is to disable FTU.

I was able to learn a couple more things - FTU is definitely loading and being set to the foreground - in ShadowThebesLayerOGL, we're being forwarded valid new pixels when I force FTU to repaint I verified with this (damnably useful!) patch that FTU is in the final CompositorParent layer tree we're trying to draw to screen. Breaking on the ShadowThebesLayerOGLs under the FTU layer tree and asking for [1] doesn't dump anything. The returned image is 0x0. That's disturbing. So one possibility is that these layers are ending with bad textures somehow. I'll see if I can test that. [1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/opengl/ThebesLayerOGL.cpp#138

This patch doesn't make the white screen go away, which is odd diff --git a/gfx/layers/opengl/ThebesLayerOGL.cpp b/gfx/layers/opengl/ThebesLayerOGL.cpp --- a/gfx/layers/opengl/ThebesLayerOGL.cpp +++ b/gfx/layers/opengl/ThebesLayerOGL.cpp @@ -1064,16 +1064,21 @@ ShadowThebesLayerOGL::Swap(const ThebesB AutoOpenSurface newFront(OPEN_READ_ONLY, aNewFront.buffer()); if (currentFront.Size() != newFront.Size()) { // The buffer changed size making the current front buffer // obsolete. DestroyFrontBuffer(); } } + + mBuffer = nullptr; + + + if (!mBuffer) { mBuffer = new ShadowBufferOGL(this); } if (nsRefPtr<TextureImage> texImage = ShadowLayerManager::OpenDescriptorForDirectTexturing( gl(), aNewFront.buffer(), WrapMode(gl(), ALLOW_REPEAT))) { // We can directly texture the drawn surface. Use that as our new I'm afraid I'm out of time on this. See above for multiple workarounds.

Guys, if we have a gfx-inclined person who has some free cycles, I can help guide through the remaining steps to diagnose (and hopefully fix) this bug. It would be very very nice to fix.

This is almost certainly related to a bug Vivien let me know of, where the homescreen doesn't render either. (FTU has a white background, and homescreen doesn't have one, so it's likely the subtrees for both are just not rendering.)

Mass closing as we are no longer working on b2g/firefox os.

Mass closing as we are no longer working on b2g/firefox os.