Our <select multiple> has enough padding so that both sides take more space that
one list item, and since this test sets the height explicitly and <select> has
box-sizing: border-box by default, page-up / page-down steps through one less
item than what the test expects.
I think this is a test bug, but let me know if you want some bug on file to
consider reducing this padding for non-native theme.
Differential Revision: https://phabricator.services.mozilla.com/D66239
--HG--
extra : moz-landing-system : lando
Clamping of the blur radius depends on transform scale factors. This info is not available until later in the WebRender pipeline, so we need to delegate blur radius clamping to WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D65804
--HG--
extra : moz-landing-system : lando
Our <select multiple> has enough padding so that both sides take more space that
one list item, and since this test sets the height explicitly and <select> has
box-sizing: border-box by default, page-up / page-down steps through one less
item than what the test expects.
I think this is a test bug, but let me know if you want some bug on file to
consider reducing this padding for non-native theme.
Differential Revision: https://phabricator.services.mozilla.com/D66239
--HG--
extra : moz-landing-system : lando
A similar reasoning as in bug 1540176 applies here as well: Pending a possible
rework of the AutoMaybeDisableFontInflation logic (bug 1619749), inflation
containers generally cannot take the (I)size increase of font inflation into
account during shrink-wrapping, and form controls like buttons are particularly
hard hit, as
a) they often contain only small amounts of text and
b) unlike regular "inline-block" elements such as <div>s, they aren't font
inflation flow roots either, and as such are therefore subject to the full
amount of font inflation from their surrounding contents,
so they are more likely to end up with a situation were the inflated text won't
fit the ISize of the button even with word wrapping applied.
Therefore, as a quicker fix, buttons will now also specifically prevented from
becoming font inflation containers.
This also has the added advantage that they thereby become subject to the logic
from bug 708175 - i.e. if the button has a fixed width, we will no now no longer
inflate its text.
Differential Revision: https://phabricator.services.mozilla.com/D66097
--HG--
extra : moz-landing-system : lando
Buttons with a fixed height are already correctly prevented from inflating, so
their test already passes. Everything else will be done subsequently.
Differential Revision: https://phabricator.services.mozilla.com/D66096
--HG--
extra : moz-landing-system : lando
Having MotionPathData in layers::Animation is a bit inefficient for animations
other than transform like properties.
Differential Revision: https://phabricator.services.mozilla.com/D65921
--HG--
extra : moz-landing-system : lando
parser/htmlparser/tests/crashtests/515533-1.html most cleanly creates this crash if you repeat it many times.
It contains an iframe to a local file (so it's a same process iframe). The document in the iframe has an inline script that does
window.location.replace("data:text/plain,");
since crashtests have the pref browser.tabs.remote.dataUriInDefaultWebProcess set (to get more testing of fission) this makes the iframe now in a different process from it's parent.
When the bug happens we create the retained nsDisplaySubDocument before the process change, the document inside the iframe has a presshell, and importantly, it does not yet have a root frame. Then the remoteness change happens on the iframe, ResetFrameLoader is called on the nsSubDocumentFrame to remove the old frame loader. So now the nsSubDocumentFrame can't find a presshell (either via views or the frameloader).
The reason that the document in the iframe not having a root frame when the nsDisplaySubDocument is created is important is because if we had a root frame then the root frame would be the mFrame of the nsDisplaySubDocument and when the root frame got destroyed for the remoteness change that frame destruction would make sure that the nsDisplaySubDocument cannot be re-used. The nsSubDocumentFrame sticks around though, so the nsDisplaySubDocument doesn't think anything changed.
Differential Revision: https://phabricator.services.mozilla.com/D65888
--HG--
extra : moz-landing-system : lando
Also, move UpdateFlexLineAndItemInfo() from the end of DoFlexLayout() to
the end of Reflow() because I'm going to extract the computation of
final size of flex container into a helper method in a later patch, and
call it Reflow() just after DoFlexLayout().
Differential Revision: https://phabricator.services.mozilla.com/D65783
--HG--
extra : moz-landing-system : lando
This is a preparation patch for a later part. I want to extract the
computation of flex container's ReflowOutput into a helper method, and
call the helper in Reflow().
Differential Revision: https://phabricator.services.mozilla.com/D65780
--HG--
extra : moz-landing-system : lando
For two reasons,
1. Change the naming to make it consistent with `ComputeCrossSize`.
2. Make it a flex container methods because it likely needs to call
nsSplittableFrame::GetEffectiveComputedBSize() later when we consider
fragmentation. If not, it doesn't harm anyway.
Differential Revision: https://phabricator.services.mozilla.com/D65778
--HG--
extra : moz-landing-system : lando
Currently, when using ReflowChildFlags::ApplyRelativePositioning flag in
FinishReflowChild(), we (implicitly) force the callers to pass aWM and
aPos in the same writing-mode as the reflow input, i.e. the child's
writing-mode. This results in an unintuitive LogicalPoint conversion
`mContainerSize - mMetrics.PhysicalSize()` in
nsBlockReflowContext::PlaceBlock().
We should allow the callers to use their preferred aWM and aPos (either
in parent's wm or child's wm), and do the necessary conversion in
FinishReflowChild() (like we did to convert aDesiredSize from
ReflowOutput's wm to aWM).
Also, correct the documentation for aWM in ReflowChild() and
FinishReflowChild(). aWM doesn't need to be the containing frame's
writing-mode. It can be any as long as it is the writing-mode that aPos
is used.
Differential Revision: https://phabricator.services.mozilla.com/D65859
--HG--
extra : moz-landing-system : lando
It seems webrender has some invalidation issues on the test reference and won't
paint the selected text on time. Instead, run the selection ASAP so that it
hopefully paints soon enough.
Differential Revision: https://phabricator.services.mozilla.com/D66108
--HG--
extra : moz-landing-system : lando
Currently the RefTest manifest parser has 5 possible statuses:
0 => EXPECTED_PASS
1 => EXPECTED_FAIL
2 => EXPECTED_RANDOM
3 => EXPECTED_DEATH (aka skip)
4 => EXPECTED_FUZZY
In the manifests, the last status annotation that appears on the line will take
precedence. For example:
skip-if(true) fails-if(true) == test1.html ref.html
fails-if(true) skip-if(true) == test2.html ref.html
The first test will have an expected status equal to EXPECTED_FAIL, whereas the
second one will be EXPECTED_DEATH. The same holds true for any combination of
'fail/random/skip/fuzzy' annotations. This means developers need to be very
careful about the order they specify these annotations as getting the order
wrong can easily lead to unexpected behaviour.
With the introduction of defaults in bug 1616368, the risk of unexpected behaviour
is far greater. Since defaults are simply prepended to the test line, a manifest
that looks like:
defaults skip-if(true)
== test1.html ref.html
fails-if(true) == test2.html ref.html
will actually skip the first test, but run the second (since the fails-if
overwrites EXPECTED_DEATH with EXPECTED_FAIL).
The root of the problem appears to be that 'skip' and 'fuzzy' are not actually
test statuses. They are modifiers that affect how we run the test, but don't
actually affect whether the test is expected to pass or fail.
Therefore, this patch solves the problem by making 'skip/skip-if' its own thing
that does not get overwritten by other failure types. In otherwords, a 'skip-if'
can appear before or after a 'fails-if' and it will have the same meaning.
Differential Revision: https://phabricator.services.mozilla.com/D64457
--HG--
extra : moz-landing-system : lando
I was working around stopDelta always being 0 for conic-gradient since it doesn't have a gradient line and disabled the essential normalization code. This patch fixes the definition of stopDelta for conic gradients and re-enables the normalization code.
Differential Revision: https://phabricator.services.mozilla.com/D65994
--HG--
extra : moz-landing-system : lando
`nsFrameConstructorState::ProcessFrameInsertions` has a 600+ byte stack frame due to its `AutoTArray`s. If this function becomes indirectly inlined into the recursive parts of `nsCSSFrameConstructor`, that will bloat the callers' stack frames and make us pay 600 bytes at every level of recursion. Crashtests aren't happy about that on stack-limited Win32 builds.
This inlining has not yet happened in official builds, but did occur in my try runs for bug 1619461 where the inliner became more aggressive.
Differential Revision: https://phabricator.services.mozilla.com/D65815
--HG--
extra : moz-landing-system : lando
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
Other browsers allow this and the spec doesn't really disallow it, so fix it,
add a test and carry on.
Differential Revision: https://phabricator.services.mozilla.com/D65107
--HG--
extra : moz-landing-system : lando
Emilio Cobos Álvarez
Mirko Brodesser
shindli
Hiroyuki Ikezoe
cbrewster
Dorel Luca
Mike Shal
Jan Henning
Daniel Varga
Timothy Nikkel
Ting-Yu Lin
Narcis Beleuzu
Ehsan Akhgari
Andrew Halberstadt
Andrew Osmond
Tim Nguyen
David Major