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
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 : commitid : JnQ0skxiHW4
extra : rebase_source : 56bdfd947334bd03035046cb24f6bebfbce32d12
extra : histedit_source : aabcffd7434755a4978971a8da238253b15948b6
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 : 572d1ff35a02505f452fee67130b48c8df4499b5
extra : histedit_source : 0b8f087bc6d70fa42401f4a2476898139bdf606c
A few notes: the test is live, so I've marked it @Ignore, so that it
doesn't run during |mach gradle test|. There's some value in mocking
the service endpoint, but this is how I verify that the server works,
so it has more value right now as a live test than a mocked test. In
the future, that probably won't be true.
There are issues running the test locally because Robolectric doesn't
provide all the cipher suites we use in GlobalConstants: in
particular, the GCM suites aren't supported. This may improve as
Robolectric matures, or we may add a work-around in the code (like at
http://androidxref.com/4.4.4_r1/xref/libcore/support/src/test/java/libcore/java/security/StandardNames.java#68),
or we may add a test-specific flag. For now, I'm not going to address
it directly.
Finally, I put the code in mobile/android/services, simply because the
less that goes into base, the better our build times will be.
--HG--
extra : commitid : Gw8uCqVViMC
extra : rebase_source : 7d35b78cb776fbd3892a2a95190a61846e0a3291
extra : amend_source : dfa8168eaca0a44b05a71fe6fdf4952964460d79
This seems more consistent with what Android UI callbacks do. This commit also
means all callees must be adapted to use the background thread if needed.
--HG--
extra : commitid : AlGQZ8biFZn
I'm slightly concerned we're providing too much configuration information in
the debugging statements.
--HG--
extra : commitid : 6JfBA5lVkZ4
extra : rebase_source : 6cf1befef3aba37031e7fc3306b446e87114b601
