On my machine this test takes ~5200 ms with the anonymous content style
caching pref disabled, and ~1000 ms with it enabled.
Differential Revision: https://phabricator.services.mozilla.com/D36139
--HG--
extra : moz-landing-system : lando
* Rename the browser.urlbar.onQueryReady event onBehaviorRequested to make its purpose and return value clear.
* Add a browser.urlbar.onResultsRequested event that's fired when a query starts so that providers can add results. Listeners should return an array of Result objects. Add the Result type. It has a `payload` property that can be an arbitrary object depending on the result type.
* Add a browser.urlbar.onQueryCanceled event that's fired when a query is canceled.
* Rename the QueryContext type to just Query. From an extension's point of view, there's no difference between Query and QueryContext like there is for the internal implementation, so "Context" is unnecessary imo.
* Internally, remove the extension listeners map from UrlbarProvidersManager. Instead, extension listeners are added directly to UrlbarProviderExtension instances, and then UrlbarProvidersManager just loops through extension providers, not a separate map of listeners.
* Since UrlbarProviderExtension is getting a little bigger, move it to its own file.
* Fix a bug in UrlbarMuxerUnifiedComplete where the heuristic result sometimes does not come first in the sorted results, depending on the timing of when results from UrlbarProviderUnifiedComplete and other providers are added.
* Move SkippableTimer to UrlbarUtils.jsm, add a logger property, and add a name property so that it's easy to figure out which timers time out.
* Add lots of tests.
Differential Revision: https://phabricator.services.mozilla.com/D34809
--HG--
extra : moz-landing-system : lando
Two benefits:
1) Align test setup with shipping Firefox - We don't allow content
privilege XUL in shipping versions of Firefox, so having the tests be
chrome would be more realistic to our use case.
2) Support the XUL to XHTML migration. These files will soon become XHTML
files, but will still need to load XUL elements, so they'll need to be
marked as chrome privileged to continue working.
Differential Revision: https://phabricator.services.mozilla.com/D34782
--HG--
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
This effectively avoids the mkdir failures I see with the 29.0.11 emulator
on packet.net with Android 7.0 x86_64. I hate to add this sort of complication
but it really helps clear the way for an otherwise useful upgrade.
Differential Revision: https://phabricator.services.mozilla.com/D34740
--HG--
extra : moz-landing-system : lando
From the CSSOM View spec[1];
The scroll-behavior property of the HTML body element is not propagated to
the viewport.
The reason why this change fixes the test case in this commit is that we don't
have two different scrollable frames for <html> and <body> respectively if we
don't propagate scroll-behavior property from <body> to <html> so that we can
properly find the `flow root` of sticky position elements.
In other words, in the case where both of <html> and <body> have properties
that are propagated from <body> but they are different we have two scrollable
frames as a candidate of the 'flow root' for the sticky position element in
the test case, one is the scrollable frame for <html> and the other is the
scrollable frame for <body>. That means that
nsLayoutUtils::GetNearestScrollableFrame doesn't return what we want in some
places, for example we have a pretty similar issue in case of
overscroll-behavior which is bug 1561107.
Note that the test position-sticky-root-scroller-with-scroll-behavior.html is
almost copy-and-pasted from
/css/css-position/position-sticky-root-scroller.html [2] in wpt, the reason why
we put the test in /css/cssom-view is that there is a handy function to wait
for async scroll completion.
[1] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
[2] https://searchfox.org/mozilla-central/rev/928742d3ea30e0eb4a8622d260041564d81a8468/testing/web-platform/tests/css/css-position/position-sticky-root-scroller.html
Differential Revision: https://phabricator.services.mozilla.com/D35739
--HG--
extra : moz-landing-system : lando
The function will also be used for `scroll-behavior` property in a later patch
in this commit series, so it needs a more reasonable name.
Differential Revision: https://phabricator.services.mozilla.com/D35738
--HG--
extra : moz-landing-system : lando
This is pretty much the same as ScrollStyles::IsSmoothScroll right now,
but in the next commit, we will no longer propagate scroll-behavior on <body> to
the root element so that nsIScrollableFrame::IsSmoothScroll will be changed
to reflect it.
Differential Revision: https://phabricator.services.mozilla.com/D35737
--HG--
extra : moz-landing-system : lando
If optional arrays of SharedScriptData are empty, avoid storing their
offset in order to save memory. This is done by deduplicating offsets
and storing this variably-sized set of offsets as a trailing array. A
uint32_t for each non-empty array. These offsets are analogous to the
array length we would naively consider storing but with careful encoding
for performance.
Differential Revision: https://phabricator.services.mozilla.com/D34791
--HG--
extra : moz-landing-system : lando
Add a flag into the byte array area. It is inserted before code() so it
will be at a fixed offset once atoms are removed. This will be used to
store flags about optional trailing arrays.
Differential Revision: https://phabricator.services.mozilla.com/D34789
--HG--
extra : moz-landing-system : lando
Now that PrivateScriptData contains a single array, the PackedSpan
mechanism for packing multiple trailing arrays can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D35817
--HG--
extra : moz-landing-system : lando
These arrays contain only relocatable, cloneable data and should be made
shareable. The API they now expose in SharedScriptData uses Span.
Differential Revision: https://phabricator.services.mozilla.com/D34790
--HG--
extra : moz-landing-system : lando
Pad the source notes with SRC_NULL such that the code and notes arrays
together maintain uint32_t alignment. This is will later be used to add
optional trailing arrays with uint32_t alignment. The allocator would
already be rounding up our allocation so actually memory usage should be
neutral.
Differential Revision: https://phabricator.services.mozilla.com/D34788
--HG--
extra : moz-landing-system : lando
Make access to trailing arrays more consistent with other data
structures and better encapsulate the reinterpret_casts.
Differential Revision: https://phabricator.services.mozilla.com/D34787
--HG--
extra : moz-landing-system : lando
As PrivateScriptData contains less data, we need to make this test have
more complicated functions so that the test is not sensistive to
allocator rounding. This also removes the binjs variant of test until
they next time they are regenerated.
Differential Revision: https://phabricator.services.mozilla.com/D35840
--HG--
extra : moz-landing-system : lando
We clamp earlier (parse time rather than computed value time), but that's the
only behavior change, which I think doesn't really matter.
Differential Revision: https://phabricator.services.mozilla.com/D35198
--HG--
extra : moz-landing-system : lando
This needs https://github.com/eqrion/cbindgen/pull/362, but I expect it to be
uncontroversial. I'll add a patch to this bug when it's merged to update it.
cbindgen historically didn't include these, but it turns out to be pretty useful
to generate constants for the style crate (since the binding crate is
`servo/ports/geckolib`).
An alternative is to get a completely different cbindgen-generated header for
these, but that seems a bit wasteful. This generates the constants with the
Style prefix (so we'll get `StyleMAX_GRID_LINE` for example), which is very
ugly. But we probably want to eventually stop using the Style prefix and use a
namespace instead, plus it's trivial to do `auto kMaxLine = StyleMAX_GRID_LINE`,
for example, so it's probably not a huge deal.
Another alternative would be to use associated consts, which _are_ generated by
cbindgen. Something like:
```
struct GridConstants([u8; 0]);
impl GridConstants {
const MAX_GRID_LINE: i32 = 10000;
}
```
Which would yield something like:
```
static const int32 StyleGridConstants_MAX_GRID_LINE = 10000;
```
I'm not sure if you find it preferrable, but I'm also happy to change it in a
follow-up to use this.
We need to fix a few manual C++ function signature definitions to match the C++
declaration.
Differential Revision: https://phabricator.services.mozilla.com/D35197
--HG--
extra : moz-landing-system : lando
Option<> is not FFI-safe, so if we want to use the same representation
everywhere we need to get rid of it. This also makes it take the same amount of
memory as the C++ representation, and it's not very complex, I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D35195
--HG--
extra : moz-landing-system : lando
