This patch implements the auto resizing to handle the MDB_MAP_FULL error. It adds two resizing strategies: 1). Active resizing to increase the store size when it gets opened; 2). Passive resizing to increase the store size when the write transaction encounters the MDB_MAP_FULL error. There are no changes to kvstore APIs, existing consumers will get this feature working without any changes to their code.
Differential Revision: https://phabricator.services.mozilla.com/D32216
--HG--
extra : moz-landing-system : lando
Recent CSP changes added some new stacks to big page leaks, so add
LoadInfo to some WPT white lists.
Differential Revision: https://phabricator.services.mozilla.com/D32501
--HG--
extra : moz-landing-system : lando
There are two related problems this patch is trying to address. The first, and
simpler, one is bug 1553436: there are websites that use existing variables and
functions named "u2f" and adding a non-replaceable readonly property with that
name on Window breaks them. The fix for this is straightforward: mark the
property [Replaceable].
The second problem, covered by bug 1551282, involves sites that use the Google
U2F polyfill. The relevant parts of that polyfill look like this:
'use strict';
var u2f = u2f || {};
u2f.register = some_function_that_only_works_right_in_Chrome;
u2f.sign = some_function_that_only_works_right_in_Chrome;
The failure mode for that code before this fix is that the assignment to "u2f"
throws because it's a readonly property and we're in strict mode, so any code
the page concatenates in the same file after the polyfill does not get run.
That's what bug 1551282 is about. The [Replaceable] annotation fixes that
issue, because now the polyfill gets the value of window.u2f and then redefines
the property (via the [Replaceable] setter) to be a value property with that
value. So far, so good.
But then we need to prevent the sets of u2f.register
and u2f.sign from taking effect, because if they are allowed to happen, the
actual sign/register functionality on the page will not work in Firefox. We
can't just make the properties readonly, because then the sets will throw due
to being in strict mode, and we still have bug 1551282. The proposed fix is to
make these accessor properties with a no-op setter, which is exactly what
[LenientSetter] gives us.
The rest of the patch is just setting up infrastructure for generating the
normal bits we would generate if "sign" and "register" were methods and using
that to create the JSFunctions at the point when the getter is called. The
JSFunctions then get cached on the u2f instance object.
Differential Revision: https://phabricator.services.mozilla.com/D32357
--HG--
extra : moz-landing-system : lando
We're moving to IR-level PGO instrumentation for clang-cl. We've also
moved to using static linker ordering files, which was the primary
application of the previous style of PGO instrumentation. We therefore
we no longer need this code.
Differential Revision: https://phabricator.services.mozilla.com/D31134
--HG--
extra : moz-landing-system : lando
This form of instrumentation is more like our other platforms, and also
opens the possibility of interacting properly with Rust IR-level PGO.
Differential Revision: https://phabricator.services.mozilla.com/D31133
--HG--
extra : moz-landing-system : lando
The idea is that we should only generate concreate-binding (wrap methods, etc)
machinery for an interface by default if we have reason to expect that the
interface is used as the primary interface for some objects. Two clear signals
that would indicate that are the interface being a leaf interface (with no
descendants) and the interface having a constructor. Other cases would require
a 'concrete' annotation in Bindings.conf.
Differential Revision: https://phabricator.services.mozilla.com/D32208
--HG--
extra : moz-landing-system : lando
This should keep people from marking things concrete unnecessarily just so
their example-generated WrapObject works.
Differential Revision: https://phabricator.services.mozilla.com/D32207
--HG--
extra : moz-landing-system : lando
We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
Changes:
- demote all existing `android-em-4.*` tests to tier 2
- ensure the above tests only run on `try` and `mozilla-central` but with exceptions
Differential Revision: https://phabricator.services.mozilla.com/D32086
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-suppress-baseline-002.html, the test currently indirectly
relies on the 50px-tall-canvas being the tallest thing in each flex
container. This isn't robustly true (and in fact on windows, the textarea is
taller at 50.8px tall). So I'm adjusting this test so that it no longer has a
hardcoded flex container size and no longer depends on this.
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
This includes style system and layout update. I add 3 extra reftests
because the original tests use ray() function as the offset-path, but we
don't support it. It'd be better to add tests using a different type of
offset-path.
The spec issue about the serialization:
https://github.com/w3c/fxtf-drafts/issues/340
Differential Revision: https://phabricator.services.mozilla.com/D32212
--HG--
extra : moz-landing-system : lando
As a plus this gives us an API we could use if we ever need to rotate the keys
at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D32335
--HG--
extra : moz-landing-system : lando
The last use of scm level in mozharness is in `mozharness.mozilla.secrets` which
uses the `MOZ_SCM_LEVEL` environment variable directy.
Differential Revision: https://phabricator.services.mozilla.com/D20897
--HG--
extra : moz-landing-system : lando
We use ".pset" to find active tables, but in Bug 1353956, v4 prefix files
are renamed to ".vlpset".
This patches include both 'pset' and 'vlpset' to ScanStoreDir.
Differential Revision: https://phabricator.services.mozilla.com/D32433
--HG--
extra : moz-landing-system : lando
The requestor should be ourselves: the toplevel docshell that the tabgroup does
not need to look in when doing the search.
Differential Revision: https://phabricator.services.mozilla.com/D32422
--HG--
extra : moz-landing-system : lando
To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
