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
During shutdown, we may find ourselves attempting to release and shutdown a probe while the PerformanceStats service is already shutdown. In this case, since the probe is already shutdown, we can simply ignore the error.
--HG--
extra : transplant_source : %BBT%84%26.%AD%7B%23%1C%BC%3F%85%F9%18%A3%D8%84%EC%02%BE
Initialize all WebMBufferedParser members, mainly to remove compiler warnings.
'mClusterTimecode' and 'mClusterOffset' are probably genuine potential issues,
see bug 1143096 comment 2 for details.
* Long pressing on empty input -> show the ActionBar.
* Single tapping on input (either empty or non-empty) -> do not show the
ActionBar.
--HG--
extra : commitid : aZIT7pP6PH
extra : rebase_source : 04066a72acfe0f75a36cb52068284f9d7e3c8284
Per request in bug 1240917 comment 15, we decided not to show caret when
single press on an empty input. This effectively reverts the work in Bug
1230582.
--HG--
extra : commitid : IjKGpqAR6zP
extra : rebase_source : d476618b4f419cf2d96bb33264cfd8ccb6e3fa61
Try to avoid capturing during transitions between changes (e.g. loading throbbers and window size transitions).
--HG--
extra : commitid : 24mODdE1TMY
extra : rebase_source : 0338e53023b9b2d7abe87637299565a1bae6115d
When a preference impacting about:debugging changes, the current tab will be rendered
again. Each "target" is responsible for checking if Debugging should be allowed.
If not, the debug button should be disabled. Currently only extensions/addons
can be disabled, depending on the value of the "devtools.chrome.enabled" preference
Adds a mochitest checking this scenario.
--HG--
extra : commitid : 9u3zEZONyBG
