Let's release a 2.5 simulator! Also seems best to hide 3.0 to reduce confusion. Currently marking this to depend on Mulet conversion, which would be nice to have.

Here is some tweaks to allow building the simulator xpis for all platforms. Requires unzip for win32, but also 7zip and sudo for Mac! So it passing a dmg is meant to be done manually. Hopefully, once Mac/Win builds are ready on Taskcluster, it can get access to a tarball...

According to Axel, it would be good to complete this task before the upcoming marketing campaign (Nov. 3).

Rebasing after bug 1213011 changes.

I messed up with mulet's process names in webide... It was wrong for windows and mac.

I don't know how we missed that??

And finally, the build script tweaks, that allows me to manually craft the xpi for all platforms. I took the "officials" mulet binaries: https://index.taskcluster.net/v1/task/gecko.v1.mozilla-central.latest.linux.mulet.opt/artifacts/public/build/target.linux-x86_64.tar.bz2 http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/firefox-44.0a1.en-US.win32.zip http://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/firefox-44.0a1.en-US.mac64.dmg Checkout lastest gaia and gecko, which are still used for 2.5. And that gave 3 xpi, I uploaded the linux one, as the other ones are not working due to binary name mismatch in webide: http://people.mozilla.org/~apoirot/ I'm quite sad about the webapps actors change, especially for windows and mac, as we don't have any mulet nightly build :'(

Comment on attachment 8680689 [details] [diff] [review] fix mulet process name - v1 Review of attachment 8680689 [details] [diff] [review]: ----------------------------------------------------------------- Are you sure about this? Shouldn't they all use `-bin`? Regular Firefox certainly has it, at least on Mac.

Comment on attachment 8680690 [details] [diff] [review] Enable mulet's support in webapps actors Review of attachment 8680690 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/server/actors/webapps.js @@ +22,5 @@ > const UNSAFE_PERMISSIONS = Services.prefs.getCharPref("devtools.apps.forbidden-permissions"); > +const IsMulet = false; > +try { > + // This pref is only defined on mulet, so it will crash on other runtimes > + IsMulet = Services.prefs.getBoolPref("b2g.is_mulet"); This is kind of crazy, should we just add MOZ_MULET to AppConstants.jsm? Then check it with: require("devtools/shared/system").constants.MOZ_MULET Wouldn't that be more natural than a pref for something does not change at runtime?

Comment on attachment 8680705 [details] [diff] [review] tweak simulator build script Review of attachment 8680705 [details] [diff] [review]: ----------------------------------------------------------------- ::: testing/taskcluster/scripts/builder/build-simulator.sh @@ +61,5 @@ > +rm -rf $WORK_DIR/ > +mkdir -p $WORK_DIR > + > +# If mulet isn't a file, that's an URL > +# and needs to be downloaded first Nit: this could probably be one line @@ +68,5 @@ > + MULET=$WORK_DIR/$(basename $URL) > + wget -O $MULET $URL > +fi > + > +# Compute asbolute path for all path variables Nit: absolute @@ +79,5 @@ > + > +mkdir -p $ADDON_DIR > + > +# Uncompress the Mulet package > +if [[ $MULET =~ .dmg$ ]]; then You should use `hdiutil attach ...` to manipulate the dmg. See examples in tree[1]. I would assume it will exist in TC once it is building Mac Firefox, since it's used there too... [1]: https://dxr.mozilla.org/mozilla-central/search?q=hdiutil&case=true&=mozilla-central&redirect=true

Oh, I didn't knew about this AppConstants! Actually, testing for MOZ_B2G is what we need and greatly simplify the whole check. Graphene also set MOZ_B2G=1. http://mxr.mozilla.org/mozilla-central/source/b2g/graphene/confvars.sh#53

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #9) > Comment on attachment 8680689 [details] [diff] [review] > fix mulet process name - v1 > > Review of attachment 8680689 [details] [diff] [review]: > ----------------------------------------------------------------- > > Are you sure about this? Shouldn't they all use `-bin`? Regular Firefox > certainly has it, at least on Mac. Oh. You are right, Mac has both firefox and firefox-bin. But this is still wrong on Windows.

Added hdiutil so that this script may run on mac. Still need to actually test this on a Mac! Otherwise, until the script is really run on Mac via automation, it is meant to be run from linux in order to build all platforms xpis.

(In reply to Alexandre Poirot [:ochameau] from comment #12) > Created attachment 8682007 [details] [diff] [review] > Enable mulet's support in webapps actors - v2 > > Oh, I didn't knew about this AppConstants! > Actually, testing for MOZ_B2G is what we need and greatly simplify the whole > check. > Graphene also set MOZ_B2G=1. > http://mxr.mozilla.org/mozilla-central/source/b2g/graphene/confvars.sh#53 As well as B2GDroid: http://mxr.mozilla.org/mozilla-central/source/mobile/android/b2gdroid/confvars.sh#9

Actually, the process name is firefox-bin on mac, but the path isn't special anymore!

Just had an issue with readlink -f which isn't supported on Mac. Replace with realpath() helper function.

I had to tweak that for tests... It looks like xpcshell appinfo ID was one of the whitelisted one, so launch/close requests were expected to work on xpcshell tests. I workaround that by allowing test to control an attribute on the webapps actor.

Comment on attachment 8682040 [details] [diff] [review] fix mulet process name - v3 Review of attachment 8682040 [details] [diff] [review]: ----------------------------------------------------------------- ::: devtools/client/webide/modules/simulator-process.js @@ +227,5 @@ > if (!file.exists()) { > file = this.addon.getResourceURI().QueryInterface(Ci.nsIFileURL).file; > file.append("firefox"); > let binaries = { > + win32: "firefox.exe", Hmm, it's odd that /browser does not package the *-bin version on Windows... but that does appear to be what happens! @@ +228,5 @@ > file = this.addon.getResourceURI().QueryInterface(Ci.nsIFileURL).file; > file.append("firefox"); > let binaries = { > + win32: "firefox.exe", > + mac64: "firefox-bin", It's possible this may change depending on other comments of how the add-on is built, so we should change this if we do end up using the full .app again.

Comment on attachment 8682045 [details] [diff] [review] tweak simulator build script Review of attachment 8682045 [details] [diff] [review]: ----------------------------------------------------------------- ::: testing/taskcluster/scripts/builder/build-simulator.sh @@ +101,5 @@ > + sleep 1 > + i=$(expr $i + 1) > + done > + # Now we can copy everything out of the $MOUNTPOINT directory into the target directory > + cp -r $WORK_DIR/dmg/FirefoxNightly.app/* $ADDON_DIR/firefox Would it make more sense to copy the whole .app into the add-on? Then it is more like the old add-ons. Or you prefer it this way? Also, this current copy put the items *inside* `Contents` into `firefox`, but later parts of this script assume `Contents` still exists inside `firefox`. @@ +124,4 @@ > > # Not sure it is still useful with mulet... > # remove useless stuff we don't want to ship in simulators > +rm -rf $ADDON_DIR/firefox/gaia $ADDON_DIR/firefox/B2G.app/Contents/MacOS/gaia $ADDON_DIR/firefox/B2G.app/Contents/Resources/gaia These lines are not currently correct on Mac, since both .app and Contents are removed. Anyway, I am pretty sure your comment is correct: Mulet does not ship a Gaia profile, so can't we just skip this entirely? @@ +137,4 @@ > > +if [ -f $ADDON_DIR/firefox/application.ini ]; then > + APPLICATION_INI=$ADDON_DIR/firefox/application.ini > +elif [ -f $ADDON_DIR/firefox/Contents/Resources/application.ini ]; then At the moment, the `Contents` segment does not exist when built on Mac, so this fails.

- Removed duplicated gaia removal code - Keeps FirefoxNightly.app as-is. Given how mac is complex, it may help us in future to have the whole app as-is. This time I tested both patches from end to end on Mac (with hot-reload to save myself from building on mac \o/).

Comment on attachment 8682435 [details] [diff] [review] tweak simulator build script Review of attachment 8682435 [details] [diff] [review]: ----------------------------------------------------------------- Okay, it works well on Mac! Have you tested the Windows version?

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #26) > Have you tested the Windows version? Yes, it also works!

https://hg.mozilla.org/integration/fx-team/rev/7a6d5c81c20b61dc5f4019c281ad7e5304e99997 Bug 1198877 - Tweak simulator build script to accept any platform package. r=jryans https://hg.mozilla.org/integration/fx-team/rev/fe64243252eda160241764270538a813293e7ec4 Bug 1198877 - Fix mulet's simulator process name used in WebIDE. r=jryans https://hg.mozilla.org/integration/fx-team/rev/e751acdc52a69c2c16a842be200e04f32fd7596d Bug 1198877 - Enable mulet's support in webapps actors. r=jryans

https://hg.mozilla.org/mozilla-central/rev/7a6d5c81c20b https://hg.mozilla.org/mozilla-central/rev/fe64243252ed https://hg.mozilla.org/mozilla-central/rev/e751acdc52a6

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/7a6d5c81c20b https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/fe64243252ed https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/e751acdc52a6

Still have to release the xpi. Unfortunately, I discovered many things being broken: - I don't know why, but webspeech is on by default and app name is spoken everytime you open an app - we don't have home button anymore - settings actor is broken or something... we can't access settings from WebIDE.

Ok, so the webspeech issue seems to be only on master and not on 2.5. Regarding the home button, that's expected as we explicitely disable the software home button from shell.html for mulet. That to avoid having responsive design and this one. I tried enabling gaia home button, but that doesn't work either. It looks like it is incompatible with gestures. So... the only way I found was having a custom build of mulet :/ https://treeherder.mozilla.org/#/jobs?repo=try&revision=370c29366bf6 Hopefully, it will build on all 3 platforms as there is no build for 2.5 anyway... I added some logs in this build to try to figure out what is going on with settings, it doesn't make sense, it should work.

\o/ at least, try is still building mulet for all 3 platforms!

removing the b2g 2.5 flag since this commit has been reverted due to an incorrect merge, sorry for the confusion

Ok, so. The speech issue was just a regression on master. The software buttons should work with bug 1225142. I'll first try to build 2.6 builds, then uplift the patches to get 2.5 builds.

Try builds for master: https://treeherder.mozilla.org/#/jobs?repo=try&revision=23dd9f326dfa

It seems to be good this time. I just need this additional patch. I built xpi for all platforms locally and currently trying to upload them. There is still the settings actor that doesn't work on mulet, but I would like to release 2.6 versions even with this regression.

Here is also an optional tweak to allow building out of try builds. Try doesn't build with MOZ_OFFICIAL and so aren't branded FirefoxNightly but just Nightly.

Could you take a look at them to see if they look good to you? http://people.mozilla.org/~apoirot/2.6/

I looked at linux and windows ones.

I tried the 2.6 build on OS X 10.11 with the current Firefox Nightly. The simulator does not launch. There is a second Nightly icon visible in the dock after clicking "Firefox OS 2.6" in the WebIDE, but no simulator. All the apps on the left side in the WebIDE are without names. After clicking one of the apps there is a yellow infobar with the following text: "Operation failed: running app (notSupported): Not B2G. Can't launch app".

I don't know why, but DebuggerServer.addBrowserActors is called earlier in mulet's simulators. Before the top level window is ready and so it prevents registering the actor.

I tested these new builds on linux64 and windows and works great, and with settings! http://people.mozilla.org/~apoirot/2.6/ Could you please take a quick look and request for signature?

https://hg.mozilla.org/integration/fx-team/rev/d98a4f77e6bdfb5cfdc4898a167e08624ccfba40 Bug 1198877 - Enable software buttons on simulators r=jryans https://hg.mozilla.org/integration/fx-team/rev/0813cd7d9f31d88057adde9ae5c7ec14946f358c Bug 1198877 - Fix settings supports for mulet's simulators. r=jryans https://hg.mozilla.org/integration/fx-team/rev/4a5ad4d3df92bda0d3138befc40cbf6084714d79 Bug 1198877 - Support building FxOS simulators from try builds. r=jryans

At the moment, the Mac build is unfortunately not working really. It "starts", and WebIDE connects to it, but no window appears. It seems many key files are missing from the base Mac Mulet package. I'll see if I can find anything about this.

Okay, I have more details. It seems like it's just an issue with whatever Mulet you used as the base? If I take the args that the simulator wants to pass: ./firefox-bin -profile /Users/jryans/Library/Application\ Support/Firefox/Profiles/i9e2tppc.development/extensions/fxos_2_6_simulator@mozilla.org/profile -start-debugger-server 62945 -screen 320x570 -no-remote -chrome chrome://b2g/content/shell.html but instead I run them from a clean Mulet (not the one inside the add-on), then it runs correctly. The Mulet files in the add-on seem very different from the clean Mulet I found... The working Mulet I used came from: https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/firefox-45.0a1.en-US.mac64.dmg The one is add-on seems to missing some files, most binary files are 2x larger for some reason, fonts directory is missing, etc.

https://hg.mozilla.org/mozilla-central/rev/d98a4f77e6bd https://hg.mozilla.org/mozilla-central/rev/0813cd7d9f31 https://hg.mozilla.org/mozilla-central/rev/4a5ad4d3df92

I uploaded new builds: http://people.mozilla.org/~apoirot/2.6/ I was doing too many things at once last week... I pushed firefox builds instead of mulet on my try push. These builds are using today's nightlies instead. This time I verified it worked on mac!

Okay, this build looks good on Mac for me as well. :D I'll open a new bug to get them signed.

Okay, I have released the 2.6 simulators. Here is a terrible list of steps I used: https://gist.github.com/jryans/c1cdc71ea55a40dc6ca8 It should probably become a real script to save our sanity. I also removed 3.0 and added 2.6 in the index.(json|html). 2.6 should appear in WebIDE when the cache clears.

We can compile this version of simulator for linux32 and win64?, have plan to do this?

(In reply to Pochy from comment #55) > We can compile this version of simulator for linux32 and win64?, have plan > to do this? Unfortunately, no. That would be something to raise to fxos team. We would need from them to build Mulet on these platforms. There is no much we can do at devtools level. I don't think there is much value in having win64 builds.

Ya, But what is the problem?, what is different or changed from 2.2(there are all architectures) to 2.6, which does not allow create the simulator for these architectures?. I say win64 because in the future should be have version of Firefox for win64 and I do not know if the simulator for win32 would be compatible with Firefox win64. But like you say Mulet could be the answer the problem.

I think we are done here. 2.6 is all what we need given the recent announcement around fxos.