When launching a B2G-Desktop build, has your testing been brought to a grinding halt due to the blank screen of death?
I was the victim of exactly the above scenario during the course of the last week as my focus shifted almost exclusively to working on Gaia, the UI layer of FirefoxOS. As with most new projects one get’s involved with, one of the first steps is getting a working development environment set-up. With Gaia there are basically three options, and the one you choose, depends on either your stage of development or, the module you are currently working on. I am not going to go into to much detail here about your options, but suffice it to say, at some stage you will touch all three.
Now, as mentioned before, my problems started when I loaded up a B2G-Desktop build using my own working profile of Gaia. After installing the dependencies, I ran the following command:
/Applications/B2G.app/Contents/MacOS/b2g-bin -profile
/Users/sneethling/mozilla/projects/gaia/profile
I was greeted not with the home screen but instead, with a pure white, blank screen and absolutely nothing being written to stdout to give me a hint as to why this is happening. I headed over to the Hacking Gaia page on the Mozilla Wiki to see if there was anything related to this problem, and indeed there seemed to be. When reading more of the details though, I realized this was not exactly what I was running into however, the second possible problem seemed plausible.
From here on then you can follow along to determine whether this is what is causing your desktop build to break as well. Head over to $GAIA_HOME/profile/extensions/httpd/content/ and open up the httpd.js file and find the following line:
/** True if debugging output is enabled, false otherwise. */
var DEBUG = false; // non-const *only* so tweakable in server tests
This is then the variable we want to set to true to enable logging of the process. After doing this start up the desktop build again. NOTE: Be careful not to rebuild you Gaia profile at this time as it will overwrite your change from above.
When the build starts up now, you will see some logging output being written to stdout. Your mileage might vary but, in my case I saw output similar to the following: “port 8080 x number of pending connections…”. That definitely sounds like there might be another process bound to 8080 so, the next step is to find that process.
Before looking at how we can find the offending process I want to take a short detour that will surely save time for some of you. If you are running CrashPlan, chances are 99% that this is the offending process but, as it also turns out, it is not port 8080 that is the trouble maker but instead port 4242 to which B2G opens socket, that is the real issue here. Nevertheless, below we will fix both possible problems.
if CrashPlan
Open up the CrashPlan UI and click on Settings and then under the General tab, click on the Configure button next to ‘Inbound backup from…….’ and change the listen port from it’s default of 4242 to something like 4142 and click Ok.

Now, load up b2g-bin again and everything should be as expected.
if !CrashPlan
If you are not running CrashPlan, then we have to dig a little deeper to find the problem. In the terminal execute the following:
sudo lsof | grep -i 'listen'
The command might take a little while to complete depending on the number of process running at the moment. Once it returns, you will see output similar to the following:

On the far right of the above is where we want to look for a process that is listing on either port 8080, 4242 (if you look at the output when starting b2g you will see a socket as opened on this port) or even 2424 as all of these are known to cause conflicts. Once you have a found the process, and identified the application, you can kill the process by taking it’s id, in the second column from the left, and running kill -9 ‘id’ from the terminal. Once the process is terminated, go ahead and load up b2g-bin again. This time, as with the CrashPlan fix, everything should work as expected.
Thing is though, it is not always desirable to simply kill a process running on port 8080 and you might wonder, why can I not just change the port for Gaia? Well, you can. To do this, build your profile as follows:
GAIA_PORT=9090 DEBUG=1 make
With the above Gaia will now bind to port 9090 and no longer 8080. If you make the above change, remember to update your hosts file so it also maps to the same port. For the socket port of 4242 however, you will have to follow the steps above.
I closing then. Now that everything works you may find that, dependent on how many times you went through the trail and error process, once the desktop build does start up, you are welcomed with a screen similar to the one below:

In more cases then not, the last one would be the one you want. Having said that, to select a homescreen every time before you can interact with the lock screen can get annoying so, if you want to get back to only one clean profile, you should run:
rm -Rf profile/
DEBUG=1 make
I hope this helps you to get up and running quickly and contributing to Gaia and FirefoxOS. On a final note, I wish to call out and thank James Lal (lightsofapollo) for all his assistance during my debugging experience.