Also move the impl to the .cpp file to avoid expensive rebuilds when it
is modified.
Differential Revision: https://phabricator.services.mozilla.com/D37589
--HG--
extra : moz-landing-system : lando
This is the easy fix.
The hard fix (outlined in the comment) would be nice, but I don't think this bug
alone justifies it.
Differential Revision: https://phabricator.services.mozilla.com/D38184
--HG--
extra : moz-landing-system : lando
The referrerInfo in SheetLoadData and StyleSheetInfo should be
different. One is used to load a style sheet and the other is used to
load resources referenced by a style sheet.
Differential Revision: https://phabricator.services.mozilla.com/D36477
--HG--
extra : moz-landing-system : lando
This will have 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.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
It wasn't working because it was testing inline size == NS_UNCONSTRAINEDSIZE
rather than block size, so it was taking always the reflow path.
The attached test is on par with the vertical-lr / horizontal-tb cases with
this patch, but takes way over 10s without it.
Differential Revision: https://phabricator.services.mozilla.com/D37437
--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
NOTE: This test relies on our wrong behavior that Element.scrollIntoView works
across the cross-origin document boundaries, which is bug 1561754. So once
after we make 'Find in page' work in fission world (bug 1553384), we should
revise this test.
Differential Revision: https://phabricator.services.mozilla.com/D36137
--HG--
extra : moz-landing-system : lando
browserElement_ScrollEvent.js is affected by this change. Before this change
the document for iframe mozbrowser was not considered as the root content
document, but after this change, it's considered as the root content document.
Given the nature of iframe mozbrowser, I believe it's the right behavior.
The browser mochitest in this commit fails without this change since
the minimum-scale size is used in the out-of-process iframe so that the visual
viewport size gets 3x bigger than the expected size.
Differential Revision: https://phabricator.services.mozilla.com/D36547
--HG--
extra : moz-landing-system : lando
Before this patch, we would use fallback for all border images. Now for
all but vector images we will use the WebRender border images
primitives. Vector images are an exception because the fallback is
clever in that it upscales the vector image and clips to only draw the
region it requires. This avoids artifacting but to do something similar
for WebRender as it is currently defined, we would increase our CPU and
memory footprint as we would need to produce the entire vector image
upscaled, not just the parts we need. In the future we should change
WebRender to accept different image resources for each of the segments.
Differential Revision: https://phabricator.services.mozilla.com/D37093
When window is resized, the cue would usually be zoomed in or out automatically with the video and keep its relative position to video.
However, if video is being applied the explicit percentage value on its 'width' or 'height', we have to recompute cue's position in this situation, because the width or height of the video would be scaled again after applied the first size scaled which is caused by resizing.
Differential Revision: https://phabricator.services.mozilla.com/D36138
--HG--
extra : moz-landing-system : lando
Without the change a green rectangle in each reftest in this commit covers whole
screen.
Differential Revision: https://phabricator.services.mozilla.com/D37328
--HG--
extra : moz-landing-system : lando
This makes us pass web platform test contain-layout-baseline-004.html (i.e. it
makes us treat that test's 'contain:layout' table-cell as having no baseline,
so we align its bottom edge with the other cell's actual baseline, as the test
expects).
This is required by the spec text at [1] which excludes most table parts but
includes table cells, and says "the containing element is treated as having no
baseline".
[1] https://drafts.csswg.org/css-contain/#containment-layout
Differential Revision: https://phabricator.services.mozilla.com/D37118
--HG--
extra : moz-landing-system : lando
I missed in bug 1487216 that the pres arena memory reporting assumes that the
entry indices are frame class ids, which means that we're reporting some display
list arena entries as frames, which is obviously wrong.
Cleanup a bit nsPresArena to remove the custom id concept, and report also
individual display item type memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D35368
--HG--
extra : moz-landing-system : lando
As far as I can tell, the intermittent suite_start failures are due to
stdout/stderr output interleaving -- a known issue for reftest logging,
without a clear way forward. Let's work around it the same way we did
on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37023
--HG--
extra : moz-landing-system : lando
Due to the sheer number of tests that exhibit a random fuzz with maxDifference=1
and maxDifference=2 with WR on Android, it's easier to just tweak the harness
to autofuzz these away. This adds machinery to do so, and also adds a new
annotation that can be used to disable the autofuzzing on specific tests.
Depends on D36794
Differential Revision: https://phabricator.services.mozilla.com/D36796
--HG--
extra : moz-landing-system : lando
The sideways-rl test is fuzzy (even without webrender) because we get a 1px discrepancy
in baseline positioning for the rotated text; presumably the rotation done by sideways-rl
and that done by CSS transform end up rounding the center of rotation differently. That's
probably a bug we should fix, although offhand I'm not sure which is more correct; anyhow,
it's a separate issue from the bug here.
When WebRender is enabled, the test/reference difference is much greater because many of
the glyphs are wildly misplaced, not just shifted by 1px, so it still fails despite the
fuzzy() annotation.
Differential Revision: https://phabricator.services.mozilla.com/D36793
--HG--
extra : moz-landing-system : lando
We should also check IsRootContentDocumentCrossProcess instead of
IsRootContentDocument there, it will be fixed in bug 1562505.
The test case in this commit is almost copied-n-pasted from
helper_scroll_into_view_bug1516056.html.
Differential Revision: https://phabricator.services.mozilla.com/D36556
--HG--
extra : moz-landing-system : lando
(The single line that made them active was commented out in the previous patch.)
Differential Revision: https://phabricator.services.mozilla.com/D36425
--HG--
extra : moz-landing-system : lando
This simplifies dealing with frames that are pushed/pulled between
continuations during reflow, allows us to avoid the complexity of the
fix to 1459937, and hopefully fixes some of the regressions from bug
1308876.
This disables the changes from bug 1459937 by commenting out a single
line in ReparentFrameInternal in nsBlockFrame.cpp, but all the added
code will be removed in the following patch.
Co-authored-by: Gerald Squelart <gsquelart@mozilla.com>
Co-authored-by: L. David Baron <dbaron@dbaron.org>
Depends on D36423
Differential Revision: https://phabricator.services.mozilla.com/D36424
--HG--
extra : moz-landing-system : lando
Actually, long tap can set focus. But since it uses `nsIFocusManager::FLAG_BYMOUSE` flag, we cannot recognize whether setting focus is by long tap or not.
So I would like to add new flag `FLAG_BYLONGPRESS` and `CAUSE_LONGPRESS` that are by long tap.
Differential Revision: https://phabricator.services.mozilla.com/D35991
--HG--
extra : moz-landing-system : lando
This will display something like:
```
error: static_assert failed due to requirement '528UL <= 504UL' "Style struct became larger than the size limit"
static_assert(Actual <= Limit, "Style struct became larger than the size limit");
^ ~~~~~~~~~~~~~~~
note: in instantiation of template class 'AssertSizeIsLessThan<nsStylePosition, 528, 504>' requested here
STYLE_STRUCT_RESET(Position)
^
note: expanded from macro 'STYLE_STRUCT_RESET'
^
note: expanded from macro 'STYLE_STRUCT'
static_assert(AssertSizeIsLessThan<nsStyle##name_, sizeof(nsStyle##name_), kStyleStructSizeLimit>::instantiate, "");
```
Which includes both the size, the limit, and the struct name, as opposed to the
current:
```
error: static_assert failed due to requirement 'sizeof(nsStylePosition) <= kStyleStructSizeLimit' "nsStylePosition became larger than the size limit"
STYLE_STRUCT_RESET(Position)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: expanded from macro 'STYLE_STRUCT_RESET'
^~~~~~~~~~~~~~~~~~
note: expanded from macro 'STYLE_STRUCT'
static_assert(sizeof(nsStyle##name_) <= kStyleStructSizeLimit, \
```
Which only includes the name and thus isn't very useful.
Differential Revision: https://phabricator.services.mozilla.com/D36546
--HG--
extra : moz-landing-system : lando
This will have 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.
One test (404149-1.xul) is now disabled, since it fails when loaded as
chrome. Bug 1557383 was filed to address this.
Differential Revision: https://phabricator.services.mozilla.com/D33986
--HG--
extra : moz-landing-system : lando
With retained display lists, a content render root might get marked as not
needing a build, in which case the nsDisplayRenderRoot::CreateWRCommands
function does an early exit. In this case, we don't mark the associated
WebRenderUserData as used during the display list build, which causes it to
get deleted at the end of the transaction. The next transaction that
doesn't early-exit will re-create the WebRenderUserData with a new boundary
object. The compositor therefore thinks it's a brand new thing and, if
conditions are right, could end up destroying and re-creating much of the
APZC tree. That in turn can have effects like discarding paint-skipped
scrolling.
This patch ensures we always touch the WebRenderUserData during the display
list build, so we don't discard it. This problem may still affect nested
nsDisplayRenderRoot instances but I don't think we ever cases where those
occur.
Depends on D36386
Differential Revision: https://phabricator.services.mozilla.com/D36387
--HG--
extra : moz-landing-system : lando
The bounds attribute has been deprecated and shown zero use, and thus this change removes it.
Differential Revision: https://phabricator.services.mozilla.com/D36005
--HG--
extra : moz-landing-system : lando
After the deleted logic
```
aFinalSize.BSize(wm) =
std::max(aReflowInput.AvailableBSize(), aContentBSize);
```
aStatus changes to incomplete, so it computes the same thing again.
Differential Revision: https://phabricator.services.mozilla.com/D36290
--HG--
extra : moz-landing-system : lando
No need to call GetEffectiveComputedBSize() twice.
Also, calling aState.ConsumedBSize() instead of using
aState.mConsumedBSize directly because the accessor function caches
mConsumedBSize properly when it is called the first time.
Differential Revision: https://phabricator.services.mozilla.com/D36289
--HG--
extra : moz-landing-system : lando
This patch only moves the logic, and rename some variables. More
clean-up follows.
Note in the middle of ComputeFinalBSize(), ShouldAvoidBreakInside() can
do early return under the condition that aStatus is complete. The logic
moved in this patch is executed only when aStatus is *incomplete*, so no
behavior is changed after applying this change.
Differential Revision: https://phabricator.services.mozilla.com/D36288
--HG--
extra : moz-landing-system : lando
Note that this is an imperfect implementation, in that it doesn't exactly
match the sizing behavior of a truly empty `<select>` element. I've filed
followup bug 1562057 on that. However, the behavior that's implemented
here *does* successfully make us ignore a `<select>`'s contents for sizing
purposes, and it's much better than what we do currently (which is pretty
broken via inheriting a partial `contain:size` implementation from our
parent class, nsBlockFrame).
Differential Revision: https://phabricator.services.mozilla.com/D36253
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
Two less properties, now that we're not using nsStyleCoord for them we can do
this.
Unfortunately the grid resolved value code needs to serialize it still, so this
doesn't remove as much code.
Also fix the script since the generated file was renamed.
Differential Revision: https://phabricator.services.mozilla.com/D36349
These changes are needed for consistently green runs with the new emulator with
"-gpu on".
Most changes are simple removal of fuzzy-if(geckoview) but I also needed to add
at least one new fuzzy-if.
In this configuration we can run reftests in just 2 chunks (20 minutes each on
opt/30 minutes on debug).
Differential Revision: https://phabricator.services.mozilla.com/D36258
--HG--
extra : moz-landing-system : lando
And move the useful bits of it somewhere else (ServoStyleConstInlines.h for the
inline function definitions, and nsFrame.cpp for the static assertions).
Differential Revision: https://phabricator.services.mozilla.com/D36120
--HG--
extra : moz-landing-system : lando
Some `nsRange` static methods are useful in `StaticRange` and some of them
are used in a lot of places but not related to `nsRange` directly. This
patch moves them into new static method only class, `mozilla::RangeUtils`.
Differential Revision: https://phabricator.services.mozilla.com/D35142
--HG--
extra : moz-landing-system : lando
For avoiding confusion between API of `nsRange` and `StaticRange`, I'd like to
rename `nsRange::CreateRange()` to `nsRange::Create()` because
`StaticRange::CreateStaticRange()` is too long name and
`StaticRange::CreateRange()` sounds odd. This patch renames it and changes
related methods to template methods to avoid runtime cost of temporary
`RawRangeBoundary` instance creation.
Differential Revision: https://phabricator.services.mozilla.com/D35141
--HG--
extra : moz-landing-system : lando
The arguments for the respective container elements apply to their immediate
child items, too: They establish a new formatting context as well and presumably
represent page content that can be considered to be logically separate enough to
warrant individual consideration for font inflation.
Differential Revision: https://phabricator.services.mozilla.com/D35881
--HG--
extra : moz-landing-system : lando
Our algorithm for dividing a page up into separate font inflation flow roots
seems mostly based on the idea that a new Block Formatting Context (BFC) should
go hand in hand with a font inflation flow root.
Flex containers so far didn't follow that rule, since they technically create a
new *Flex* Formatting Context (FFC) and possibly also because nobody thought
about font inflation when implementing nsFlexContainerFrame.
This leads to all flex containers being counted against the next higher-level
flow root, meaning that a lot of small flex containers can get inflated if their
sum total of text *collectively* exceeds the font inflation threshold.
This alone is likely undesired most of the time, but is then also aggravated by
the fact that our flexbox behaviour under font inflation is somewhat buggy (bug
1142461).
As apart from the different layout rules inside the container, a FFC behaves
very much like a BFC in that it establishes a new formatting context, flex
containers should therefore correspondingly become font inflation flow roots,
too, and therefore be considered individually for font inflation.
As far as I can tell, with this change we'll also match Blink's behaviour in
that regard.
For completeness's sake, we'll make grid containers follow the same principles,
even though hopefully grids on non mobile-friendly pages should hopefully be
somewhat rarer than flexboxes.
Differential Revision: https://phabricator.services.mozilla.com/D32622
--HG--
extra : moz-landing-system : lando
In this case, the desired end state is *no* inflation, so we don't need separate
ref-versions of the test pages - the only difference is in the prefs being used.
Differential Revision: https://phabricator.services.mozilla.com/D32621
--HG--
extra : moz-landing-system : lando
There is a natural tendency to add new tests at the bottom of the manifest, so
the comment about the lineThreshold pref wasn't entirely accurate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D32620
--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/D35870
--HG--
rename : dom/xul/test/test_bug486990.xul => dom/xul/test/test_bug486990.xhtml
rename : layout/base/tests/file_bug465448.html => layout/base/tests/chrome/file_bug465448.html
rename : layout/base/tests/test_bug465448.xul => layout/base/tests/chrome/test_bug465448.xul
extra : moz-landing-system : lando
This change updates a large number of reftests to link to the
`/fonts/ahem.css` stylesheet. Each file contains a single additional
line before the first `<style>` element:
```
<link rel="stylesheet" type="text/css" href="/fonts/ahem.css" />
```
Differential Revision: https://phabricator.services.mozilla.com/D35958
--HG--
extra : moz-landing-system : lando
reftest manifests have ordering issues, re-organizing the fuzzy-if/random-if clauses to allow random-if to work.
Differential Revision: https://phabricator.services.mozilla.com/D36031
--HG--
extra : moz-landing-system : lando
The patch also removes the dom.vr.oculus.quit.timeout pref, because it's
unused.
Differential Revision: https://phabricator.services.mozilla.com/D35973
--HG--
extra : rebase_source : bd16ed5ff0b7c2b4f8e653e9835610b25b14a39f
The issue with using the same mechanism as scroll events is that overflow events
that result from a layout flush from the refresh driver tick don't happen until
the _next_ refresh driver tick. That's bad and causes a few tests that don't
wait enough to fail. I guess the next alternative is what PostDOMEvent uses,
which is just dispatch to the event loop.
This is actually green and also fixes the bug for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D35769
It caused rendering issues just like a reftest in this commit. We don't know
the reason but fixing it will be some amount of work which couldn't be uplifted
to 68. So we just revert the change here now. Probably we should revisit the
problem once we got a bug report that the lack of the `transform-style: inherit`
causes rendering issues.
Differential Revision: https://phabricator.services.mozilla.com/D35946
--HG--
extra : moz-landing-system : lando
Use the geckoview TestRunnerActivity, org.mozilla.geckoview.test, by default
for all types of mochitests, reftests, and web-platform tests. TRA is already
the default for gtest and geckoview-junit. Fennec, based on ANDROID_PACKAGE_NAME,
remains the default for robocop and marionette-test and I have no plans to
change those. There is a related issue for xpcshell-test -- not the package
name, but the default apk -- but I am reluctant to handle that until bug 1553225
is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D35479
--HG--
extra : moz-landing-system : lando
This doesn't change the way C++ code uses static prefs. But it does slightly
change how Rust code uses static prefs, specifically the name generated by
bindgen is slightly different.
The commit also improves some comments.
Differential Revision: https://phabricator.services.mozilla.com/D35764
--HG--
extra : rebase_source : 13cf215aeb713e188103ef0cd04d094aa150853e
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
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
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
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
'<image>' elements will look at the current clip when painting. Puting one
of them at negative coordinates exposes potential bugs in the blob recoord work.
Differential Revision: https://phabricator.services.mozilla.com/D36072
--HG--
extra : moz-landing-system : lando
If we decide to just go with an overlay that sits fully over the
window (which I don't personally see a perf problem with right now,
but correct me if you can think of one), then this should be all
we need.
Differential Revision: https://phabricator.services.mozilla.com//D33819
--HG--
extra : rebase_source : 44a5af47f9c10071b0933931fbf3708978f549e4
That includes changing privacy.resistFingerprinting to a non-VarCache pref,
because it doesn't need to be a VarCache.
Differential Revision: https://phabricator.services.mozilla.com/D36162
--HG--
extra : rebase_source : 6d742e6ff2a4b786cb21f6e8874d1fd4bbde1857
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
mark w3c-css/submitted/variables/variable-external-font-face-01.html as random-if on win7/debug
Differential Revision: https://phabricator.services.mozilla.com/D35653
--HG--
extra : moz-landing-system : lando
Correctly handle clamping to 1 behavior of grayscale(),
invert(), opacity() and sepia().
Differential Revision: https://phabricator.services.mozilla.com/D35509
--HG--
extra : moz-landing-system : lando
This restores our previous and per-spec behavior. Comparing only ratios was not
correct in the case one of the dimensions was zero and thus not scaled.
Differential Revision: https://phabricator.services.mozilla.com/D35571
--HG--
extra : moz-landing-system : lando