[rfc] Investigations into loading Fennec's Gecko resources (chrome, components, and modules) from the assets/ directory

Nick Alexander nalexander at mozilla.com
Mon Feb 24 12:09:29 PST 2014


Hello mobile-firefox-dev,

As you may have noticed [1], 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 [2].

*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 [3], which is immediately 
actionable.

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 [4] [5] 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 [6].

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 
features.

Thanks for reading!
Nick

[1] 
http://www.ncalexander.net/blog/2014/02/14/getting-started-with-the-android-eclipse-build-backend-for-fennec/

[2] 
https://mail.mozilla.org/pipermail/mobile-firefox-dev/2013-April/000035.html

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=976216

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=873569

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=887121

[6] https://bugzilla.mozilla.org/show_bug.cgi?id=948465#c7


More information about the mobile-firefox-dev mailing list