According to: https://developer.mozilla.org/nl/Firefox_OS/B2G_desktop_client_gebruiken#Running_on_Mac " If you downloaded the nightly build, you can simply launch it from the Finder as usual. Any console output is visible by running the standard Console utility program included with your Mac. " So after downloading https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/b2g-39.0a1.multi.mac64.dmg and unmounting that file, the resulting B2G.app file should just be able to run fine on MacOS X. The profile directory seems to have moved inside the B2G.app file (it's under resources now).

Kevin, do you know what's going on here and what needs to get fixed to get this working again?

Probably bug 1089710 or bug 1101331.

Thanks Alex. I'm not really sure what's going on here, but I'd recommend checking on the bugs that Alex mentioned, and following up with the people who fixed those bugs.

Stephen, did the patch from bug 1142605 cause this bug?

Do you mean bug 1101331? I can't say for sure. B2G desktop OSX seemed to open fine for me with the patch there. Can you test a build prior and after it landed?

Yes, sorry, I meant bug 1101331. I guess if it opened for you just fine, then it didn't happen because of that patch.

Might still be worth double-checking. That patch has gone through a number of iterations and who knows what might have happened while we were waiting to land it...

Ok, seems like it was caused by bug 1101331. I don't see the bug in a 2015-03-04 build, but I do see the bug in a 2015-03-05 build.

So, how is it that all the tests on mozilla-central for b2g desktop OSX are green when it doesn't open..?

(In reply to Stephen Pohl [:spohl] from comment #9) > So, how is it that all the tests on mozilla-central for b2g desktop OSX are > green when it doesn't open..? Well, the builds are green but after looking at this again, I'm not sure we run any tests on it. This would have caught this issue here.

Martijn, are you extracting the b2g.app from the DMG? Or are you trying to run it from the mounted DMG? I just tried to run a debug build [1] and it seemed to open fine for me after I extracted it... When you say "it doesn't open", what's displayed on screen? Any error message? Or does the simulator not look right? [1] http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-macosx64_gecko-debug/1426246219/b2g-39.0a1.multi.mac64.dmg

Yes, extracting the b2g.app from the DMG, then opening the resulting b2g.app. This is what I see: http://www.tiikoni.com/tis/view/?id=2e1a672 Are you getting something else with the .dmg file from: https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/firefox-39.0a1.en-US.mac64.dmg ?

I ran into the same issue. It's because the profile had moved. I did a work around of soft linking to the directory from where it should be to where it's now located and it's working for me with today's build. I blogged about it here : https://shizen008.wordpress.com/2015/03/13/macos-desktop-build-for-firefox-os/

So, I'm no longer sure I understand what this bug is about. The summary says that B2G can't open. Comment 12 seems to indicate that you're able to open it, but it doesn't display what you expect (if so, please attach a screenshot of what you'd expect). The missing profile would support the fact that you can't open B2G, but then I don't understand how you were able to capture the screenshot of the running B2G build. Could you clarify? Are there multiple issues here?

(In reply to Stephen Pohl [:spohl] from comment #14) > So, I'm no longer sure I understand what this bug is about. The summary says > that B2G can't open. Comment 12 seems to indicate that you're able to open > it, but it doesn't display what you expect (if so, please attach a > screenshot of what you'd expect). The missing profile would support the fact > that you can't open B2G, but then I don't understand how you were able to > capture the screenshot of the running B2G build. Could you clarify? Are > there multiple issues here? The image in comment 12 shows the program running, yes, but the screen is blank and sized strangely, which likely happen if the Gaia profile path is wrong. If I download the dmg linked in comment 11, copy the app somewhere, and double-click the app, that's the behavior I see. If I then enter the B2GDebug.app package on the terminal and run "b2g" as specified in the Info.plist, I see it in turn runs: b2g-bin --profile /Users/jryans/Downloads/B2GDebug.app/Contents/MacOS/gaia/profile But, this is incorrect, because the bundled profile is in Resources. Manually running: ./b2g-bin --profile /Users/jryans/Downloads/B2GDebug.app/Contents/Resources/gaia/profile gives the expected behavior where the homescreen appears, etc. So, the "b2g" program seems to need to change to have the new profile path.

We're basically running into the situation that I requested help with in bug 1101331 comment 7. I'm not very familiar with b2g, but offered to reorder the files regardless since I've done it for Desktop Firefox on OSX. Considering all the other work that's going on it may take me weeks before I can look into this. I'll set n-i on myself in case nobody else has time to look into this before I get back to it.

Where is the code that gives the b2g binary ?

Just to be clear, Ryan in comment 15 describes exactly the problem (thanks Ryan).

(In reply to Julien Wajsberg [:julienw] (PTO March 7th -> 15th) from comment #17) > Where is the code that gives the b2g binary ? The relevant code seems to be in "b2g/gaia"[1]. It currently appends "gaia/profile" to the current directory of the "b2g" executable, so that's how we get the current behavior. Stephen, is there a "good" way to get at files in the Resources directory, like some kind of define? Or else, I suppose we could just change "gaia/profile" to be "../Resources/gaia/profile" for Mac. [1]: https://dxr.mozilla.org/mozilla-central/source/b2g/gaia

NS_GRE_DIR (or "GreD") points at Contents/Resources on OSX, NS_GRE_BIN_DIR (or "GreBinD") points at Contents/MacOS. However, we seem to be doing C string operations on the path here, so not sure if this is of much value. If we keep the C-style string operations, we should change the path string to "Contents/Resources/gaia/profile" directly rather than "Contents/MacOS/../Resources/gaia/profile".

For what it's worth Marionette assumes the profile is in gaia/profile path relative to the binary. See http://hg.mozilla.org/mozilla-central/file/cbd0efcd976c/testing/marionette/driver/marionette_driver/geckoinstance.py#l158 Any changes should also be reflected there.

Stephen, this is still an issue. Can you work on this or do you know anyone who might be able to fix this?

No, I don't.

Pinging on this, it's still a problem.

Is it the case for the Mulet as well ?

Marking WONFTIX, sorry for the bug spam. If somebody still wants to work on this, please open a new bug.