The mathml reftest pref needs to be added at the same time because the test needs that pref with the new scrollbar code to pass, but it fails with that pref with the old scrollbar code. Since that test uses the minimum scale, which is only valid with overlay scrollbars, it is correct to do so.
Differential Revision: https://phabricator.services.mozilla.com/D91243
This change regresses partial-prerender-translate-1.html which is a test case
that we don't consider transforms making the entire element outside of the clip
rect as jank (i.e. there is nothign to be composited). That said, it won't be
a big problem since even if the jank happened on the compositor, then there is
nothing to be painted on the main-thread, moreover with step timing functions
most of animation restyling are going to be skipped on the main-thread. So
the layout.animation.prerender.partial pref for the test case is dropped.
Differential Revision: https://phabricator.services.mozilla.com/D90649
In SVG frame tree SVG{Inner,Outer}Frame is normally not scrollable but clips
descendants, thus nsLayoutUtils::GetNearestScrollableFrame is not able to find
the clip/scroll frame. So in this change, we introduce
GetNearestOverflowClipFrame which is a similar function to
GetNearestScrollableFrame but it also checks whether the frame is SVGInnerFrame
or SVGOuterFrame which is clipping the given nsIFrame during walking up the
frame tree.
In this change we also change the logic to get the clip/scroll frame and the scroll
id as follows;
1) Get the nearest overflow clip frame in the same document
2) Use the root frame if there is no clip frame
3) Then try to find the scroll id if the clip frame is asynchronously scrollable
so that it becomes clearer before. It's still messy though.
Differential Revision: https://phabricator.services.mozilla.com/D90647
In some cases (in this scenario, with a RTL XUL scrollframe), the scrollframe
can have a nonzero scroll position upon construction or reconstruction, without
having executed the scrolling code in ScrollFrameHelper::RestoreState or
ScrollFrameHelper::ScrollToRestoredPosition. In such cases APZ is not properly
notified of the scroll position, and it can get into a state where it is out of
sync with the main thread scroll position (until a subsequent scroll).
To correct this, we replace the ScrollPositionUpdate that is created during
scrollframe construction with a new ScrollPositionUpdate that holds the correct
scroll position, so that APZ is properly notified of the scroll position.
Differential Revision: https://phabricator.services.mozilla.com/D90674
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
Add an extra pixel of fuzziness for this test - a recent unrelated
change to WR thread timing made this intermittent fail more often.
Differential Revision: https://phabricator.services.mozilla.com/D90053
These tests only failed on android, probably because the visual viewport size is different so we get a different result from the scrollbar calculation.
These tests seem to have an inconsistent mix of overflow: hidden and scrollbar-width: none. The desktop zooming scrollbars sometimes create scrollbars for overflow hidden now, so overflow hidden isn't enough, we need scrollbar-width: none.
layout/reftests/transform/compound-1-fail.html is the only file modified here that doesn't have overflow hidden or scrollbar-width: none already. Looking at the test it does not seem to be wanting to be anti-ref because of scrollbars (the transformed item looks different), so this seems to be an improvement (ie we won't pass because only the scrollbar differed).
Differential Revision: https://phabricator.services.mozilla.com/D90008
This commit remove the following preferences, which have been
disabled since Firefox 70:
- mathml.nonzero_unitless_lengths.disabled
- mathml.legacy_number_syntax.disabled
These are edge syntaxes for MathML3 lengths that don't align well
with CSS and we haven't received any bug report about it since they
were disabled. Tests are updated to treat attributes using such
values as invalid.
update tests
Differential Revision: https://phabricator.services.mozilla.com/D89920
By mistake the specification used to say that, for items spanning
multiple tracks, the growth limits of the tracks with an intrinsic max
track sizing function should grow to accommodate the minimum
contribution of the item.
But this was a mistake, because an intrinsic max track sizing function
can only be min-content or max-content. So instead of distributing the
minimum contribution, it should be the min-content contribution.
The spec has been fixed and there is a CSSWG resolution in
https://github.com/w3c/csswg-drafts/issues/4790
This patch fixes the problem by reverting 2b923d48ea7e. The change is
likely web compatible, since it only affects a rare edge case with
'minmax()' where the min sizing function is 'auto' or a fixed value
smaller than the min-content contribution, the max sizing function is
'min-content', and an item whose minimum contribution is forced to be
smaller than the min-content contribution, and spans multiple tracks.
Differential Revision: https://phabricator.services.mozilla.com/D89145
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
All of these reftests end up using a minimum scale with layout/classic scrollbars. (They hit the assert from the patch in bug 1663534.)
Some of them are only written with overlay scrollbars in mind (for example overflow-hidden-region-with-negative-left-positioned-element.html which I looked at in detail).
The change that causes them to fail is the code in nsHTMLScrollFrame::TryLayout that decides if we need scrollbars. Before desktop zooming scrollbars we compared the visual viewport size and the scrolled rect size. With desktop zooming scrollbars we compare the (layout) scrollport and the scrolled rect to determine if we need regular scrollbars and then compare the visual viewport size to the (layout) scrollport to determine if we need scrollbars to scroll the visual viewport inside the scrollport. Then can get different results.
Differential Revision: https://phabricator.services.mozilla.com/D89407
For all the other scroll-behavior-* tests, the "complex" behaviour is the "test"
and the "let's scroll these things to their intended destination" behaviour is
the "ref", as one would expect. Except for some reason in scroll-behavior-6, the
"ref" branch is the one doing all the tricky scrolling things and the other
branch has the simple intended outcomes. This patch inverts the branches so
that the test behaves more as expected.
Differential Revision: https://phabricator.services.mozilla.com/D88648
SVGSVGElement::SetCurrentScaleTranslate checks that things have changed but if we
manage to update both translate values before we get here then we'll skip the screen update
that we need.
Also
- introduces a tear off for SVGSVGElement.currentTranslate so we hand out the same object as required by the SVG idl
- removes SVGSVGElement::SetCurrentTranslate as dead code
- removes mPreviousScale and mPreviousTranslate from SVGSVGElement as they are no longer necessary
Differential Revision: https://phabricator.services.mozilla.com/D84796
Although this goes against the suggestion of the sample algorithm in the
spec, this brings the layout of the multi-line column-oriented flex
container in paginated context closer to the layout with no
fragmentation. This also matches Google Chrome's behavior.
Tweak flexbox-unbreakable-child-2.html so that it matches the rendering
as of this patch. Change the height of `.muticol` and the removal of
border in `flexContainer` to let two flex items fit exactly into the
flex container's height, making reference easier to write.
Differential Revision: https://phabricator.services.mozilla.com/D87107
They're enabled in all configurations and there's no plan to change
this. With it, dom.experimental_forms is also useless, so we can remove
it too.
Differential Revision: https://phabricator.services.mozilla.com/D87623
For a given ::Reflow call, we have an expectation that the ReflowInput and
ReflowOutput should be "matching". In particular: we should use the
ReflowInput to initialize the ReflowOutput, and we should pass both of these to
the frame's Reflow method.
In current mozilla-central (prior to this patch), nsPageSequenceFrame violates
this expectation when it prepares to reflow its children, in the following
ways:
1) It passes in the wrong ReflowInput as an arg when constructing a
ReflowOutput struct for its children. (It passes *its own* ReflowInput arg,
rather than the ReflowInput for the child that it's about to reflow.)
2) It *reuses* that single ReflowOutput structure *for all of its children*,
which means that sizing information from one child will end up improperly
influencing later children by "leaking through".
This results in overflow areas that are artificially too large on nsPageFrames,
because ReflowOutput populates its overflow areas via "union()" operations. So
the improperly-reused ReflowOutput produces a strictly larger overflow area
on each subsequent page (even if the page doesn't actually have any overflow).
This patch fixes these problems by creating a new ReflowOutput for each child,
and initializing it with the correct ReflowInput instance.
Notably, this patch *is* a behavior-change (in the direction of correctness).
In particular, we won't have artificially-inflated overflow areas on later
nsPageFrame instances anymore, and so now some of our automated testcases
trigger assertion-failures that they were getting around before. These all
seem to be versions of https://bugzilla.mozilla.org/show_bug.cgi?id=1655630
which, "fortunately", is already reproducible (under certain paper sizes)
even in a build from current mozilla-central, without this here patch.
Differential Revision: https://phabricator.services.mozilla.com/D85098
`nsIFrame::ComputeISizeValue` clamps the result to non-negative before
returning it, so the assertion doesn't need to be a hard assertion.
Differential Revision: https://phabricator.services.mozilla.com/D84745
This is a test case which will fail if we didn't factor the position of the
transform from the reference frame in the jank mechanism in cases where the
transform is inside a perspective layer. In the case of non WebRender, we've
already factored it in FrameTransformToTransformInDevice() [1].
For WebRender we will need to factor it in a different way becase there is no
layer tree structures so that we can't tell whether the transform is inside
a perspective layer or not by looking at the parent layer.
Note that, as of now, this test doesn't fail on WebRender since there is no jank
mechanism on WebRender yet.
[1] https://searchfox.org/mozilla-central/rev/7ec7ee4a9bde171ba195ab46ed6077e4baaef34d/gfx/layers/CompositorAnimationStorage.cpp#276-282
Differential Revision: https://phabricator.services.mozilla.com/D83200
Without setting font and line-height, these reftests may yield different
results on different platforms because of the default font are
different. Also, their optimal column balancing height may not be an
integer in CSS pixels.
I discover this because they are failing due to 1px column height
difference after we stop searching optimal balancing height within a
certain threshold on either macOS, Windows, or Android.
Differential Revision: https://phabricator.services.mozilla.com/D83730
* floats-clear-multicol-balancing-*:
Change border-width from "normal" to "5px" so that the optimal column
height is 85px. This also makes those reftests renders the same across
all browsers since each browser renders "normal" differently.
* column-balancing-overflow-005:
This test is already wrong as its height is 13px/3 = 4.3333px, so it can
pass with some fuzzy. This patch makes the target column height
4px (including the children's overflow). This is the same as the `<p>`'s
height 4px in reference file.
* box-decoration-break-border-image:
Add 1px to .vbreak so that the optimal column balancing height is a
integer. Also, remove a whitespace between two `<span>` in `<pos2>` to make the
test more robust because the width of the whitespace is not an integer.
Differential Revision: https://phabricator.services.mozilla.com/D83729
The patches in the stack were backed out because of an unexpected pass in the resulting push.
The expectations for now-passing tests have been updated.
Differential Revision: https://phabricator.services.mozilla.com/D83987
Forgot to follow up on these two remaining non-standard values that may have
been being used to reset a <meter> or <input type=number> back to its
original appearance, but which telemetry showed no usage of.
Differential Revision: https://phabricator.services.mozilla.com/D83598
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
Fixes a missing closing tag in the retained-dl-style-change-stacking-context-3
test page. Unfortunately, this changes the structure of the page and makes the
test fail, so the reftest.list file is updated accordingly. Since the existing
test structure was clearly testing something else, and caught a legitimate
difference in behaviour with and without APZ zooming on desktop, this patch
also creates a new test with that structure (and better indentation).
Differential Revision: https://phabricator.services.mozilla.com/D82214
This hooks the "monochrome" media query and co to the
nsIPrintSettings.printInColor setting.
This print setting we're using is not exposed in the print preview UI,
but you can test it setting the print.print_in_color preference to
"false", and then print preview will correctly show up greyscale'd.
Once this lands, the UI folks just have to use it as they see fit :)
I would've liked to add a proper rendering test, but the print reftests
check only whether the PDF text matches.
I could add a test to printpreview_helper.xhtml, but I'm refactoring
that file in bug 1648064 so I'd rather wait a bit and add it in a
separate bug. The test for the media feature should make sure that we
test that code path at least.
Differential Revision: https://phabricator.services.mozilla.com/D83552
Per documentation, `aPositionedFrame` (the second argument) of
`PushAbsoluteContainingBlock` should be the frame whose style actually
makes the new absolute containing block a containing block, so it should
be the fieldset frame itself, not fieldset's inner frame.
Co-authored-by: Mats Palmgren <mats@mozilla.com>
Differential Revision: https://phabricator.services.mozilla.com/D82651
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Depends on D75731
Differential Revision: https://phabricator.services.mozilla.com/D75732
The machinery to report janked animations is;
1) Store the partial pre-rendered animation id and the Animation object in a
hashtable in LayerManager
2) Store the animation id in the Animation object as well
3) When we detect jank, we send the animation id to the main-thread via an IPC
call
4) Find the Animation object with the id in the hashtable and update the
Animaiton
5) Whenever the partial pre-rendered Animation stop running on the compositor
i.e. the Animation finished normally, the Animation's target element is
changed, etc. etc., remove the Animation from the hashtable
Differential Revision: https://phabricator.services.mozilla.com/D75732
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
Instead of using overflow:hidden on the body to hide the scrollbar, this
patch sets scrollbar-width:none on the html element. In some cases
overflow:hidden is set on non-root scrollers (i.e. div elements); in those
cases it is replaced by overflow:scroll;scrollbar-width:none to get an
equivalent effect.
One test had a pre-existing visible scrollbar on a nested scrollframe, but
which started failing with a small fuzz difference. I left the scrollbar as-is
and added an annotation to the reftest.list file.
Note that this only updates the tests that use reftest-async-scroll as those
were the cases that were easily detectable, and causing problems with the
apz.allow_zooming=true pref.
Differential Revision: https://phabricator.services.mozilla.com/D82032
When sorting frames in DOM order, we need to be careful to avoid using
an anonymous flex item's content node to make ordering decisions;
otherwise, all such items would incorrectly end up being sorted to the
front of the list. We need to dig through it to find the content node
that was wrapped in the anonymous wrapper, and use that content node for
sorting/ordering.
Differential Revision: https://phabricator.services.mozilla.com/D81001
Note that on Chrome table-row-pagination-001-print.html doesn't generate the
second page at least in the print preview. The second page is actually just a
blank page, but the height of a table element in the test is `160%` so that
there should be overflowed area from the first page.
It may be possible that it's an optimization in Chrome to reduce paper
consumption, but the second page in the reference, it's also a blank page, is
generated in the print preview, so I suppose it's either a bug or an
inconsistent optimization in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D81635
In various parts of the picture and mask code, we were casting
the `clipped` rect to i32 (after rounding out). However, this
can cause overflow panics when the origin of the rect is too big.
Instead, treat the origin as f32 (which it was generally being
converted to anyway), and only cast the size part to be i32 as
required. This is safe since we know that the size has been
clipped to the visible screen, so will always be safe to cast
to i32.
Differential Revision: https://phabricator.services.mozilla.com/D80968
This patch adds the boolean pref mathml.stixgeneral_operator_stretching.disabled, which defaults to true iff nightly.
When the pref is true, stretched operators won’t be rendered with STIXGeneral, because we only use OpenType MATH tables (in fonts that have them) or the generic Unicode table.
When the pref is false, we continue to support STIXGeneral for stretched operators, but warn the author in devtools and bump the use counter (up to once per page). This only happens when a stretched operator actually uses STIXGeneral: not when we successfully render the operator with some other font earlier in the font-family stack, and not when STIXGeneral isn’t installed.
Differential Revision: https://phabricator.services.mozilla.com/D73833
The top end of the scrollbar seems off by a subpixel amount. Some initial
investigation is documented in bug 1646527 and points to a WR internal bug.
Depends on D80089
Differential Revision: https://phabricator.services.mozilla.com/D80090
The top end of the scrollbar seems off by a subpixel amount. Some initial
investigation is documented in bug 1646527 and points to a WR internal bug.
Depends on D80089
Differential Revision: https://phabricator.services.mozilla.com/D80090