This small change is a follow-up to Bug 1242213, which did the same
for the main package. This is a nod to the future and Gradle, which
cleanly splits the internal Java package (org.mozilla.gecko) from the
external Android package (org.mozilla.fennec and friends).
--HG--
extra : commitid : 6yO5ngkvK75
extra : rebase_source : d52161ed67a995e8b73683245443c5df41c5e6db
extra : histedit_source : 125732b8ff1a173cc95b04dde8970e34044ef39c
This isn't sensible for b2gdroid, but that project should never enable
the bouncer APK anyway.
--HG--
extra : commitid : 5KSz5ooYeb1
extra : rebase_source : 71ea30ce85ba33f58d887d3f90367103f99e0eff
extra : histedit_source : cf91111ebe61f87d64c304206e4ddc409aa26535
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
--HG--
rename : mobile/android/javaaddons/Makefile.in => mobile/android/bouncer/Makefile.in
rename : mobile/android/app/assets/example_asset.txt => mobile/android/bouncer/assets/example_asset.txt
rename : mobile/android/javaaddons/moz.build => mobile/android/bouncer/moz.build
rename : mobile/android/base/resources/drawable-v21/logo.xml => mobile/android/bouncer/res/drawable-v21/logo.xml
rename : mobile/android/base/resources/drawable/logo.xml => mobile/android/bouncer/res/drawable/logo.xml
extra : commitid : 1XkuX1F0pMb
extra : rebase_source : 3154b4569efd4cccb4d5f72ff9bbff60d2744d3b
extra : histedit_source : 5e10ab9825bcf653a5a109c8e502658d52aedd79
Call a distribution in /data/data/$PACKAGE/distribution a "data
distribution". Right now we read data distributions only in response
to writing them via another code path (extracting from APK, or
downloading). We don't recognize a data distribution in the same way
that we recognize a system distribution (in /system/.../distribution)
in the Java code, simply because we don't look for it; and I haven't
investigated, but I think that Gecko may in fact recognize a data
distribution in this case.
This patch simply recognizes data distributions after looking for
other distributions. That way data distributions written by the
bouncer APK are recognized and initialized, but not given precedence
over other distribution channels.
--HG--
extra : commitid : HnKxkzVG9TW
extra : rebase_source : 9ae70f8a8012b37c6d13a2af0358a9a0891cf4d4
extra : amend_source : e581fa3a30abdeaa903be04e48a296c8da4ed482
extra : histedit_source : b2cc424a0f1f27c79d51b6632e7e923c5e742d4f
This reads from "assets/distribution/**" in the APK and writes to
"distribution/**" in the data directory. That output is the same, but
the input used to read from "distribution/**", which is not really
supported by modern build tooling (Gradle), which doesn't allow to
write files directly into the APK root.
I manually tested this without issue. I see no way to add meaningful
tests to our current Robocop test suite; the long term testing
approach is to develop a new test for this functionality and only run
it against the "distribution" build type that was added in Bug
1163080. However, that's a larger project than I have time for now.
--HG--
extra : histedit_source : aabcffd7434755a4978971a8da238253b15948b6
extra : rebase_source : 036d9eaa94f2c8293430c9e4bba2d8ac2c69e943
extra : commitid : 4AFfnZIJUHt
extra : source : baf25be8d4917e6dcc52eede79e61e1837328c86
extra : amend_source : 9839fd7f9a536e21e50530599eecf295c3067b03
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
--HG--
extra : commitid : BLgM6ZCm9AY
extra : rebase_source : a0896616f79f5a961476e4d2df9745516c58b44a
extra : source : e228040a044b7ff7363a178da2cb0b8b42724048
extra : histedit_source : 0b8f087bc6d70fa42401f4a2476898139bdf606c
While waiting for a fix at test harness level, added a helper waiting for MozAfterPaint
when running in e10s mode for all the browser_profiler_tree-abstract tests.
--HG--
extra : commitid : CvYNKvoSNBl
While investigating bug 1243549, we encountered several instances of the following error message during each startup:
*************************
A coding exception was thrown and uncaught in a Task.
Full message: TypeError: this.Paths is null
Full stack: Agent.wipe@resource:///modules/sessionstore/SessionWorker.js:296:7
worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
@resource:///modules/sessionstore/SessionWorker.js:30:41
*************************
These messages can be explained as follows:
* If sanitization has failed during shutdown, it attempts again to
sanitize during startup. This happens more often than it used to,
because of 1/ startup bug fixes in bug 1089695; 2/ new shutdown bugs
most likely also added by or around bug 1089695.
* Sanitization during startup doesn't wait until Session Restore has
properly started to sanitize the session. So sanitization of Session
Restore file fails. This has probably always been the case, except
we never noticed.
* For some reason I do not understand, it attempts to sanitize several
times.
* I suspect that this can cause problems during startup, as
sanitization and Session Restore race to use/remove the files of
Session Restore.
This patch makes sure that SessionFile.wipe() waits until
initialization of SessionFile is complete before proceeding.
gDevTools.jsm isn't properly reloadable as JSM as meant to be long-lived singletons.
Also, it contains browser related code (gDevToolsBrowser) mixed with more generic one (gDevTools).
This move is going to help hot reloading devtools codebase while improve readability of
one of our core piece of code (devtools startup and browser hooks).
--HG--
rename : devtools/client/framework/gDevTools.jsm => devtools/client/framework/devtools-browser.js
Extracted a shared helper to open the browser context menu and choose
the 'inspect element' item. This helper works with e10s.
Adapted it a little bit so it waits for the right events in order to
make sure the inspector is ready.
This also involved modifying inspectNode in nsContextMenu.js to make it
wait until the node was selected and the node was ready.
Used this in browser_inspector_initialization.js,
browser_rules_content_02.js and browser_markup_keybindings_04.js
Also removed a now useless inspector-updated event that was trigger from
the animation-inspector panel in some situation. This was left behind
from a long time ago but didn't serve any purpose anymore.
--HG--
extra : commitid : BUtFyFVXwYi
extra : rebase_source : 1553c9ebc1d8da035058552924e4ad3cd1b09f09
We assume that the total number of cycles spent executing JS code
during an event is equal to the number of cycles in the "top group",
i.e. a group to which everything belongs. While this is true in
theory, RDTSC is actually non-monotonic, so we can end up with fewer
cycles reported for the top group than for some groups whose execution
was actually shorter. When we end up in this situation, groups with
more cycles than the top group will be reported as using more CPU than
was actually used.
This patch fixes the situation by proxying RDTSC behind a trivial API
that ensures that values are monotonic during each tick.
--HG--
extra : transplant_source : %3E%8Aj%12e%B9%A7%08i%8Ef%28%F5%5D69q%15%8E%99
The current API of AddonWatcher only supports a single callback. That's pretty unfriendly to testing, debugging, add-ons, etc.
This patch replaces the mechanism with a notification through the nsIObserverService.
--HG--
extra : transplant_source : %C2%88%B1%DF%B2%B2.%A7%C7Ti%C8%A8%C0%CA0%15f%8D%C5
Nick Alexander
Julian Descottes
Wes Kocher
Mark Banner
Brian Grinstead
Victor Porof
Michael Comella
Carsten "Tomcat" Book
Dave Townsend
Edouard Oger
David Rajchenbach-Teller
Ryan VanderMeulen
Mike de Boer
Alexandre Poirot
CJKu
Phil Ringnalda
Patrick Brosset
Tracy Walker
