- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
Add js::intl::NumberFormatFields containing the two methods:
- `append`: To append a number format field
- `toArray`: To construct the result Array object
The `unitType` argument for NumberFormatFields::toArray will be used in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D26718
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
The goal is to have something simple and not relying on other tools.
I tried with licensecheck and licensee but, with if we use a different
wording to declare "public domain" (as example), they might not
catch it. Requiring to contribute upstream, etc
Instead, I just create a list of line of license to catch it.
From my trials, it works well enough and it is trivial python.
Differential Revision: https://phabricator.services.mozilla.com/D37082
--HG--
extra : moz-landing-system : lando
This is a weird pref.
First, it is VarCached into two different global variables, one in
nsSubDocumentFrame.cpp, and the other in nsView.cpp.
Second, the pref is not defined by default. When the VarCache variables are
initialized they are therefore set to the default value provided to the
`AddBoolVarCache()` call, which in both cases is `true`. This semantics isn't
possible with `StaticPrefs`, so the patch defines the pref as true by default.
Differential Revision: https://phabricator.services.mozilla.com/D37204
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
Some background information on this change:
DocShell loads about:blank when first starting up. This initial load can be
avoided by setting `nodefaultsrc` on the browser element, but this will still
cause some load events related to `about:blank` to fire anyway, as they are
specified in the DOM spec (see e.g. bz's Comment #2 Bug 1447406). In particular
`onSecurityChange` and `onLocationChange` are still fired, `onPageStart` and
onPageStop` are not.
These messages are unreliable and sometimes do not fire, to unrestand why it's
helpful to look at a timeline of the events when starting up a GeckoSession.
page about:blank ---------------------------------------------------------
nsDocShell --- startup --- onPageStart --- onLocationChange --- onPageStop -----
busyState idle ---------- busy ------------------------------------------ idle-
^ ^ ^ ^ ^
geckoview.js (0) (1) (2) (3) (4)
geckoview.js loads in parallel with nsDocShell startup process (and loading of
about:blank). This means that consumers of GeckoView might start receiving
navigation events at any of the points marked with (0) - (4). E.g. if geckoview
starts up at (4) a consumer waiting for onPageStop for `about:blank` will
actually wait forever (this is what happens before this change for our tests).
As it can be seen there's not really a way to detect in which of the (0) - (4)
state DocShell is when starting up geckoview.js. Checking for the busy state is
not enough as an `idle` busy state might mean that we're in (0) or (4).
Furthermore a consumer of geckoview has no way to know which onPageStop
messages to wait for after an initial loadUri as e.g. the following is what
would happen if geckoview.js happens to startup at (3):
- loadUri(hello.html)
- onPageStop (for about:blank)
- onLoadRequest (for hello.html)
which confuses any code that just waits for onPageStop.
Desktop deals with this in `TabProgressListener.onStateChange` where the
initial `about:blank` navigation is ignored and fake events are triggered at a
convenient time.
To patch implements a very similar behavior for geckoview, we ignore the
initial `about:blank` `onLoadRequest` call, set `nodefaultsrc` so `onPageStart`
and `onPageStop` events don't fire and fire the above calls when the
`GeckoViewProgress` module has finished loading.
This makes `about:blank` events deterministic with the exception of reloading
an empty `GeckoSession`, which will often not fire any extra events. To account
for that we load a dummy html page before the tests that used to rely on this
behavior (which would actually fail occasionally due to the startup race
condition explained above).
This makes the tests pass reliably on x86_64 (20/20 runs passed in try).
Differential Revision: https://phabricator.services.mozilla.com/D32586
--HG--
extra : moz-landing-system : lando
Right now listeners for a given native app receive messages from all
WebExtensions. This is wrong as listeners should be extension specific so that
only the intended extension can send messages to the app.
Differential Revision: https://phabricator.services.mozilla.com/D35948
--HG--
extra : moz-landing-system : lando
Reusing sessions doesn't actually save that much time and avoids a lot of
hard-to-debug intermittents.
Differential Revision: https://phabricator.services.mozilla.com/D32578
--HG--
extra : moz-landing-system : lando
Sometime the geolocation test fails because the position is not retrieved
quickly enough, this is OK as we're just trying to make sure that the
permission is correct.
Differential Revision: https://phabricator.services.mozilla.com/D32576
--HG--
extra : moz-landing-system : lando
