[rfc] Investigations into loading Fennec's Gecko resources (chrome, components, and modules) from the assets/ directory
nalexander at mozilla.com
Mon Feb 24 12:09:29 PST 2014
As you may have noticed , one of the things I care about is making it
easier to develop Fennec. Eclipse makes it much easier to build, test,
and debug the Java parts of Fennec, but it's really not helping (and it
might be hindering) us develop the JS parts of Fennec.
One idea I had about making it easier to develop the JS parts of Fennec
is to have Fennec (Gecko, really) load resources from the Fennec APK
assets/ directory (rather than requiring a rebuild of omni.ja and
therefore the Fennec APK). So I dug into learning about how Gecko loads
resources, and I have a number of tidbits to report.
You can view this work as the first thought I've had, post Eclipse
landing, since working on the Fennec bootstrapper .
*All this would only apply to developer builds.*
Here are a few thoughts:
1) The startup cache already makes it pretty difficult to develop JS
modules. |mach build mobile/android/modules && mach package && mach
install| doesn't appear to clear the startup cache, meaning that changed
code is never loaded. I've filed Bug 976216 , which is immediately
2) We have no easy way to reference Android assets. That is, we have no
equivalent of WebView's file://android_asset. I think GeckoView
consumers will want this; it's the easiest way (by far!) to ship static
assets as part of your Android application. (We already did lots of
work   to ship libraries and omni.ja itself in assets/, with an
eye to making IDE builds and shipping GeckoView-based applications
easier.) This is surprisingly easy to arrange; I've updated Bug 948465
with some thoughts .
3) Preprocessing is frustrating. It means we can't, for example,
trivially load browser.js from assets/; we would need to preprocess
browser.js into assets/. At this point, we're re-inventing packager.py.
I dug into what |mach package| actually does, and on my fast SSD,
building a fresh omni.ja takes less than 3s. So we might want to scrap
this overloading altogether and just make it easy to get a fresh omni.ja
from IDEs. I haven't spent any time trying to make this happen.
4) Overloading Gecko JS module loading is not trivial. I haven't found
a way to load every resource://gre/modules/Foo.jsm from a dynamically
determined location. I had hoped that adding a resource substitution
for gre/modules would work, but it doesn't appear to. (Corrections
appreciated.) It seems even harder to add an optional override, i.e.,
load it from A, and if that fails, then load it from B instead. Without
optional overrides, it means we have to have all of gre/modules in the
assets/ directory. We've re-invented packager.py --flat! Hurrah!
One thing that would make this easier is if resource declared in
mobile/android went into a fennec DIST_SUBDIR (like webapprt). This
would change resource://gre/modules/AndroidSpecificModule.jsm to
resource://fennec/modules/AndroidSpecificModule.jsm. Then we could
substitute resource://fennec for the assets/ directory in developer
builds. I have no idea what further repercussions this might have: for
example, do add-ons expect to load Fennec JSMs from
resource://gre/modules/? If so, we'd need to do something.
If you have context or opinions, please chime in! Together we can make
developing Fennec easier, attract more contributors, and build better
Thanks for reading!
More information about the mobile-firefox-dev