Introducing Mulet

[Jonas Sicking]

Mulet, french, noun. Half horse, half donkey.
Mullet, english, noun. Business in the front, party in the back.

Alexandre Poirot and Alexandre Lissy have been working hard on a new
development environment that should be a big improvement over both
what we use internally for Gaia development, and what we are asking
3rd party app developers to use when developing apps for FirefoxOS.

The basic idea behind this environment is to take Firefox Desktop as
it exists today (including its support for both internal and external
dev tools) and then run it using the same Gecko that we use for
FirefoxOS. So the backend half is FirefoxOS, the frontend part is
Firefox desktop.

This means that we'll have the exact same great development experience
that we have for Firefox desktop today, but we can use the real
implementation of various FirefoxOS specific APIs that we use on
devices.

One nice example of this is that we can keep the app: protocol working
in Mulet. So we don't need to rely on running a local http server and
run gaia through special http urls. Ultimately the goal is to enable
the app: protocol in Mulet to either load from a compressed zip file,
or directly from your gaia source tree.

Once Mulet is ready, it will *replace* the following development environments:
* B2G Desktop
* Gaia-on-Firefox-desktop
* Simulator

So it will be one tool that is usable for gaia developers, gecko
developers and 3rd party app developers.

The name "simulator" might still be around since it's something that
we've been evangelizing to developers a lot. But it will eventually be
based on Mulet.

The goal is to make this tool have nightly releases which works just
like firefox desktop. Or you will be able to build it yourself if you
need to depend on tip. This will require the help of the releng team
though.

Making all of this play well together is a lot of work. So any help
you can provide to Alexandre and Alexandre is very appreciated. We
want this environment to fit your needs, so we can build in whatever
features or tools that will make development better for you. But to
make that happen we'll both need your feedback and your help.

I'd like to extend a big thanks to both Alexandre Poirot and Alexandre
Lissy for working on this!

/ Jonas

[Josh Matthews]

Any information on how to take it for a spin today? Where to file bugs,
patches, see a TODO list, etc?

Cheers,
Josh

[Kartikaya Gupta]

Cool! Are there any technical docs on this? In particular I'm interested
to know if it uses the gonk widget backend and APZC code. I have a patch
that might potentially be breaking input in Mulet, depending on what
it's doing.

Cheers,
kats

[Fabrice Desré]

On 03/28/2014 08:57 PM, Kartikaya Gupta wrote:
> Cool! Are there any technical docs on this? In particular I'm interested
> to know if it uses the gonk widget backend and APZC code. I have a patch
> that might potentially be breaking input in Mulet, depending on what
> it's doing.

No, it's a desktop build, so it's using the linux/mac/windows widgetry.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Vivien Nicolas]

You can file bugs on bugzilla as usual and make them blocks
https://bugzilla.mozilla.org/show_bug.cgi?id=943878

On 29/03/2014 00:50, Josh Matthews wrote:
> On 03/28/2014 07:40 PM, Jonas Sicking wrote:

> Any information on how to take it for a spin today? Where to file bugs,
> patches, see a TODO list, etc?
>
> Cheers,
> Josh

> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g

[Vivien Nicolas]

As Fabrice says it does not use the gonk widget backend as this is a
desktop build.

For APZ the goal is to use it a the end. There is currently a lot of
issues with events and a few other things that prevent us to use APZ as if.

So for instance touch events are not native but simulated from mouse
events (see
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/touch-events.js)

Also desktop build are not yet OOP and will likely need a few things to
be fixed to works correctly before (see the list of prefs turned off on
desktop at
http://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#275 ).

So all the events are emulated from mouse events as of today in order to
generate touch events, that are forwarded to BrowserElementPanning.js
that does sync scrolling.

So basically none of the APZ code path :/

That said it would be awesome to have APZ on the Mulet, with the subtle
difference of the widget backend.

I assume that the patch you're speaking about that may break the Mulet
is about moving events to a separate thread ?


So to summary for the moment the Mulet has a lot of flaws. Especially
related to touch events, for the RIL backend, and NFC backend, Audio, etc..

But it is already a big progress in terms of unified dev environment for
many and it basically combines the advantages of 3 of the 4 different
developers environment we have today (it combines b2g-desktop, the
simulator, and Gaia extensions to develop in the browser, but does have
use all the widgetry of the device).

About APZ and all the graphics part, any help would be much appreciated
to move forward. I know that there is a lof of specific code path in the
Layers code for APZ but the Mulet is not 100% intended to completely
replace the device, but mostly to save a lot of times on daily task.

About RIL I have a local patch that compile the Mulet with the
MOZ_B2G_RIL flag and the beginning of a fake Rild implemented in JS (it
let you start calls, merge them into a conference call, receive incoming
calls, etc... but miss many ICC related features).

For NFC a similar thing than the local Rild.js daemon can probably be
implemented.

Not sure exactly about Audio and the others bits.

Vivien.

[Kartikaya Gupta]

On 29/3/2014, 22:26, Vivien Nicolas wrote:
> So all the events are emulated from mouse events as of today in order to
> generate touch events, that are forwarded to BrowserElementPanning.js
> that does sync scrolling.
>
> So basically none of the APZ code path :/
>

Ok, thanks for clarifying.

> I assume that the patch you're speaking about that may break the Mulet
> is about moving events to a separate thread ?
>

No actually the patch I had in mind was
https://bugzilla.mozilla.org/attachment.cgi?id=8398661&action=diff -
there's some code in APZ that is supposedly there for B2G emulation but
I've never seen it exercised. I thought maybe Mulet might start using it
right when I get rid of it.

> So to summary for the moment the Mulet has a lot of flaws. Especially
> related to touch events, for the RIL backend, and NFC backend, Audio, etc..
>
> But it is already a big progress in terms of unified dev environment for
> many and it basically combines the advantages of 3 of the 4 different
> developers environment we have today (it combines b2g-desktop, the
> simulator, and Gaia extensions to develop in the browser, but does have
> use all the widgetry of the device).
>

I totally agree that something like this will be very useful, but it's
important to make it clear which parts are representative of what will
be running on-device and which parts are not. If any users of this tool
assume that the panning behaviour will be the same as on-device, they
will be in for a surprise. I think there are legitimate scenarios where
users may write apps with heavy painting and see no checkerboarding in
Mulet but then get heavy checkerboarding on-device, for example.

I look forward to trying this out as soon as I get a chance! :)

kats

[Alexandre poirot]

Thanks Jonas for introducing the Mulet!

The meta bug to track Mulet's development is https://bugzilla.mozilla.org/show_bug.cgi?id=961745

I'm trying to post a new comment every time there is a major update in this bug.

I have many patches, most of them are too hacky to be landed as-is, in a personal git branch over here:
  https://github.com/ochameau/mozilla-central/tree/mulet

(For now, you have to build Firefox target with --enable-mulet option in your mozconfig, and you need to pass a gaia profile when running firefox)

Our current challenge is to figure out how to build such mixed up species,
any build system tip is welcomed on https://bugzilla.mozilla.org/show_bug.cgi?id=961745

Otherwise, I see many over-expectation about the Mulet.

The Mulet is only about merging b2g desktop and Firefox.

So that it shouldn't introduce anything new from either b2g desktop or Firefox.

We won't be running more "device code" (like APZ, widget code,...) than b2g desktop.

Actually, ensuring that we run more "device code" doesn't depend of the Mulet.

You can already improve that right into b2g desktop and the Mulet
should automatically benefit from it.

So if anyone is willing to jump on the "improve our desktop environment" train,

please feel free to contribute without waiting for the Mulet!

Anything that can make our desktop runtime act like our device runtime
is a big win for contributors, gaia developers and automatic testing!

[Jonas Sicking]

On Sun, Mar 30, 2014 at 5:39 PM, Kartikaya Gupta <kgu...@mozilla.com> wrote:
>> I assume that the patch you're speaking about that may break the Mulet
>> is about moving events to a separate thread ?
>

> No actually the patch I had in mind was
> https://bugzilla.mozilla.org/attachment.cgi?id=8398661&action=diff - there's
> some code in APZ that is supposedly there for B2G emulation but I've never
> seen it exercised. I thought maybe Mulet might start using it right when I
> get rid of it.

The first thing we need to do to get APZ on desktop is to enable
out-of-process running on B2G desktop. The first step to get *that*
happening is to start testing the gfx code out-of-process. This is
tracked here:

https://bugzilla.mozilla.org/show_bug.cgi?id=922680

Like Alexandre pointed out, there's no need to wait for Mulet to get
these things working. If we make B2G desktop run out-of-process then
Mulet will immediately benefit from that.

>> So to summary for the moment the Mulet has a lot of flaws. Especially
>> related to touch events, for the RIL backend, and NFC backend, Audio,
>> etc..
>>
>> But it is already a big progress in terms of unified dev environment for
>> many and it basically combines the advantages of 3 of the 4 different
>> developers environment we have today (it combines b2g-desktop, the
>> simulator, and Gaia extensions to develop in the browser, but does have
>> use all the widgetry of the device).
>>
>

> I totally agree that something like this will be very useful, but it's
> important to make it clear which parts are representative of what will be
> running on-device and which parts are not. If any users of this tool assume
> that the panning behaviour will be the same as on-device, they will be in
> for a surprise. I think there are legitimate scenarios where users may write
> apps with heavy painting and see no checkerboarding in Mulet but then get
> heavy checkerboarding on-device, for example.
>
> I look forward to trying this out as soon as I get a chance! :)

Mulet will make it easier for us to land things in gecko which makes
Mulet behave more like on-device.

For example rather than using addons to simulate touch events, I think
it should be doable to make gecko use the same code paths for touch
event generation in Mulet as we do on device.

But Mulet will never be an alternative to testing on device. If for no
other reason that we can't accurately mimic performance
characteristics of a device.

/ Jonas