Fix several bugs when handling arrays in GeckoBundle.
1. Correctly return null when getting an array that is not in the
bundle, instead of crashing.
2. Convert object arrays to GeckoBundle arrays in EventDispatcher
instead of leaving it as a single GeckoBundle with integer keys, due
to lack of object array support in NativeJSObject.toBundle.
3. Return error when trying to convert a JS array of arrays to
GeckoBundle, instead of crashing.
4. Add convenience methods for setting arrays; for example, setting
boolean arrays from Boolean[] and Collection<Boolean>.
The idea is that cancelling edit mode when opening a new tab implies that we want to select it as well, otherwise we wouldn't have to cancel edit mode in the first place.
MozReview-Commit-ID: Gova1ymzlHn
--HG--
extra : rebase_source : a1d957de82a5e1ec9bf9162e1f01641e34e16ab4
- poll all buffers when started or flushed.
- retry only for timed out.
- remove unnecessary polling
MozReview-Commit-ID: DU9vvjJkwDH
--HG--
extra : rebase_source : 54d734585e198413b2f1afbdad9b073b4e14a153
Currently, we stop updating closed tabs if max_tabs_undo is set to 0, however we don't clear that data and carry it around indefinitely unless the user clears the browser history.
This means that when closing a tab, we still show the "Undo close tab" snackbar, however with its contents referring to the last tab the user closed before setting browser.sessionstore.max_tabs_undo to 0.
With this patch, we clear all closed tabs (and don't reload them from disc on startup) if max_tabs_undo is 0, which also stops the snackbar from showing after closing a tab.
MozReview-Commit-ID: PEtminpW4B
--HG--
extra : rebase_source : 7c8039db1d1d7c5bc127cdc11fbc0a1387694ef9
This can happen if the users sets browser.sessionstore.max_tabs_undo to 0 - with no closed tabs available, without this fix the resulting exception breaks browser.js's closed tab handling, meaning the tab gets closed in the UI but not in Gecko.
MozReview-Commit-ID: 7yMyIB6UzAB
--HG--
extra : rebase_source : 37ca55519b30cbd5d263127d3ecd6b893ccfafc9
Update tooltool manifests to repacks of upstream builds of
rustc 1.14.0-beta.2 (e627a2e6e 2016-11-16)
cargo 0.15.0-nightly (a9c23dd 2016-11-15)
for the relevent hosts and target platforms.
We prefer to use stable rust but this bump gets us debuginfo
for the rust standard library on all platforms, which we hope
will improve crash reporting (bug 1268328). That is higher
priority. The rust 1.14 version should be in stable release
before Firefox 53 goes to Aurora, so we'll still stabilize
and ship with stable rust.
This build also contains the fix for the arm code generation
bug blocking update from 1.12 on android, so we can use 1.13
language features in Firefox 53. For more information, see
https://github.com/rust-lang/rust/pull/37815
This doesn't update the native MacOS build because of an
openssl link issue with cargo. This is resolved upstream
for rust 1.15; getting that ported to a later 1.14 beta is
tracked in https://github.com/rust-lang/rust/issues/37969
MozReview-Commit-ID: JbJTd4D7VOu
--HG--
extra : rebase_source : 0690f3d4443f3fc7f224f051f910de92c54b8f60
Run the tooltool manifests through a python script to read the
json as an OrderedDict and when write it back out with normal
tooltool formatting options. This regularizes the whitespace,
fixing trailing spaces written by older versions of the python
json serializer, dos-vs-unix line endings, and regularizing
opening '[{' and closing '}]' to be on separate lines.
The android manifests have a 'versions' key which has indenting,
unlike the rest of the files. I've left that as-is.
MozReview-Commit-ID: EVW1YlgRJJL
--HG--
extra : rebase_source : 40c1992090807dc40495ebacb37ee358c1d6a6f1
We switch to thinking of the tabs grid layout as being determined by specifying
the spacing between the items, and then allowing the items themselves to expand
to fill whatever room that leaves available, but we also allow the spacing to be
adjusted to match the span counts of the previous GridLayout implementation
(which is a good thing).
MozReview-Commit-ID: L3fgjacMu2d
--HG--
extra : rebase_source : 72e77a44c0f0c8c9de3c9d6c5ef95aad405d27a3
extra : source : 17966f55c27550e30f2ec1aab5bc6bc849240436
Wait to register MediaPlayerManager events until we have a GeckoApp
EventDispatcher, because we only have an EventDispatcher after we create
the GeckoView in onCreate.
Since we're Proguarding the automation build now, we shouldn't need to
multiDex anymore -- even in beta.
MozReview-Commit-ID: 6Yc73Vi9Fhd
--HG--
extra : rebase_source : cdfb01a47dc05dfafc4ba67cdb30f86dbd5aa4ec
moz.build achieves better results than Gradle, and I can't fully
explain why that is. At first I thought it was due to
-optimizationpasses, which is 6 for MOZILLA_OFFICIAL; however, it's
not -- I see no change (let alone an improvement), when I set the
number of passes to 1, 6, 10, or 100. I think there are two things at
play. First, moz.build strips debugging information from "libraries",
which are broadly the Google support libraries. I don't think it's
possible to strip debug information in this fine-grained manner using
Gradle. Second, I think the Gradle build might be including more code
than the moz.build configuration (see the follow-up patch removing
multidex support), but I can't determine what's actually different.
After APK compression, I see less than a 50kb regression in APK size
between Gradle and moz.build outputs, which I deem reasonable.
MozReview-Commit-ID: 4q4Zye2wnOF
--HG--
extra : rebase_source : dfc0f983f56ceb5907f9aafcb37d2ac63d50988b
<input>'s of type checkbox and radio are rendered as native widgets by default
on Desktop, but on Fennec, we fallback to using the built-in, non-native
checkboxes.
The earlier patches in this series made it possible for agent, user and page
stylesheets to make changes to the non-native checkbox and radio input fields.
Unfortunately, some of the default agent styles for those checkbox and radio
elements on Fennec were accidentally setting rules that they shouldn't. That
wasn't a problem before because the inputs couldn't be styled before. Now that
they can, we're failing a bunch of reftests because the inputs look wrong in
certain situations.
For example:
1) We were setting background: var(--form_background) for every radio and
checkbox input. --form_background is just a colour though, and that meant
that the rest of the background styles were being overwritten. This has
been fixed by setting background-color: var(--form_background) instead.
The same also applied to some usage of --form_background_disabled.
2) We were setting border-radius: var(--form_border_radius) on all input
elements, but this was putting rounded corners on the checkbox and
radio inputs as well. This rule has been modified to skip checkbox
and radio inputs.
MozReview-Commit-ID: CnpTRXcCxoY
--HG--
extra : rebase_source : ee688b96270e9b2b3498f18d43f9430048b9b444
