Closed Bug 1198877 Opened 9 years ago Closed 8 years ago

Release 2.5 simulator, hide 3.0

Categories

(Firefox OS Graveyard :: Simulator, defect)

Product:
Firefox OS Graveyard
Component:
Simulator
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox45 fixed)

Status:
RESOLVED FIXED
Milestone:
FxOS-S11 (13Nov)
Tracking Flags:
Tracking Status
firefox45 --- fixed

People

(Reporter: jryans, Assigned: ochameau)

References

Details

Attachments

(6 files, 10 obsolete files)

Enable mulet's support in webapps actors - v3
2.74 KB, patch
jryans
: review+
Details | Diff | Splinter Review
tweak simulator build script
7.08 KB, patch
jryans
: review+
Details | Diff | Splinter Review
fix mulet process name - v4
1.17 KB, patch
ochameau
: review+
Details | Diff | Splinter Review
Enable software buttons on simulators
725 bytes, patch
jryans
: review+
Details | Diff | Splinter Review
Support building FxOS simulators from try builds
2.21 KB, patch
jryans
: review+
Details | Diff | Splinter Review
Fix settings supports for mulet's simulators.
1.02 KB, patch
jryans
: review+
Details | Diff | Splinter Review 
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.
Attached patch tweak simulator build script (obsolete) — — Splinter Review 
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...
Depends on: 1213011
According to Axel, it would be good to complete this task before the upcoming marketing campaign (Nov. 3).
Attached patch tweak simulator build script (obsolete) — — Splinter Review 
Rebasing after bug 1213011 changes.
Attachment #8671355 - Attachment is obsolete: true
Attached patch fix mulet process name - v1 (obsolete) — — Splinter Review 
I messed up with mulet's process names in webide...
It was wrong for windows and mac.
Attachment #8680689 - Flags: review?(jryans)
I don't know how we missed that??
Attachment #8680690 - Flags: review?(jryans)
Attached patch tweak simulator build script (obsolete) — — Splinter Review 
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 :'(
Attachment #8680705 - Flags: review?(jryans)
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.
Attachment #8680689 - Flags: review?(jryans) → review-
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?
Attachment #8680690 - Flags: review?(jryans)
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
Attachment #8680705 - Flags: review?(jryans)
Assignee: nobody → poirot.alex
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
Attachment #8682007 - Flags: review?(jryans)
Attachment #8680690 - Attachment is obsolete: true
Attached patch fix mulet process name - v2 (obsolete) — — Splinter Review 
(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.
Attachment #8682008 - Flags: review?(jryans)
Attachment #8680689 - Attachment is obsolete: true
Attached patch tweak simulator build script (obsolete) — — Splinter Review 
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.
Attachment #8677453 - Attachment is obsolete: true
Attachment #8680705 - Attachment is obsolete: true
(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
Attached patch fix mulet process name - v3 (obsolete) — — Splinter Review 
Actually, the process name is firefox-bin on mac,
but the path isn't special anymore!
Attachment #8682040 - Flags: review?(jryans)
Attachment #8682008 - Attachment is obsolete: true
Attachment #8682008 - Flags: review?(jryans)
Attached patch tweak simulator build script (obsolete) — — Splinter Review 
Just had an issue with readlink -f which isn't supported on Mac.
Replace with realpath() helper function.
Attachment #8682045 - Flags: review?(jryans)
Attachment #8682011 - Attachment is obsolete: true
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.
Attachment #8682176 - Flags: review?(jryans)
Attachment #8682007 - Attachment is obsolete: true
Attachment #8682007 - Flags: review?(jryans)
Attachment #8682176 - Flags: review?(jryans) → review+
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.
Attachment #8682040 - Flags: review?(jryans) → review+
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.
Attachment #8682045 - Flags: review?(jryans)
- 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/).
Attachment #8682435 - Flags: review?(jryans)
Attachment #8682045 - Attachment is obsolete: true
Attachment #8682040 - Attachment is obsolete: true
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?
Attachment #8682435 - Flags: review?(jryans) → review+
(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/mozilla-central/rev/7a6d5c81c20b
https://hg.mozilla.org/mozilla-central/rev/fe64243252ed
https://hg.mozilla.org/mozilla-central/rev/e751acdc52a6
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S11 (13Nov)
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
status-b2g-v2.5: fixed → ---
Depends on: 1225142
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.
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.
Attachment #8688498 - Flags: review?(jryans)
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.
Attachment #8688499 - Flags: review?(jryans)
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.
Attachment #8688973 - Flags: review?(jryans)
Attachment #8688498 - Flags: review?(jryans) → review+
Attachment #8688499 - Flags: review?(jryans) → review+
Attachment #8688973 - Flags: review?(jryans) → review+
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?
Flags: needinfo?(jryans)
Flags: needinfo?(jryans)
Keywords: leave-open
Flags: needinfo?(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.
Flags: needinfo?(jryans)
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.
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!
Flags: needinfo?(jryans)
Okay, this build looks good on Mac for me as well. :D

I'll open a new bug to get them signed.
Flags: needinfo?(jryans)
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.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: