We had zero tests for this, and when I implemented the optimization to
avoid reframing in most cases I apparently swapped the arguments ;_;
Fix <input type=search> which suffered from the same issue, but we don't
ship by default.
Differential Revision: https://phabricator.services.mozilla.com/D155394
This is a hack, sorta, similar to Chromium's:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;l=356;drc=312b74e385e6aba98ab31fd911238c0dc16b396c
except at computed-value rather than used-value time, because it's both
simpler to reason about and prevents lying in the computed style.
This fixes the relevant test-case, and matches closer what Chromium does,
by not creating anonymous flex items for all elements inside the
line-clamp context.
The behavior change is covered by the test changes. I had to also fix a
couple pre-existing bugs that were caught by tests, now that the
line-clamped block is the -webkit-box-styled element rather than an anonymous
flex item (and thus now had padding).
Depends on D155180
Differential Revision: https://phabricator.services.mozilla.com/D155181
nsIFrame::IsContentHidden() is the proper way to check if an element
skips its contents (but just like CanUseLastRememberedSize, it doesn't
support 'content-visibility: auto' yet).
The only difference is that nsIFrame::IsContentHidden() checks that
'content-visibility' applies, but that should always be the case when
there is size containment, so this patch has no effect in practice.
Differential Revision: https://phabricator.services.mozilla.com/D156186
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
This is far from fully perfect (specially when dealing with nested
containers, we need to be smarter when updating there), but it's
incremental progress.
Differential Revision: https://phabricator.services.mozilla.com/D151496
ContainSizeAxes::ContainSize and ContainSizeAxes::ContainIntrinsicSize
were just using 0 for the axes with size containment, now they will take
contain-intrinsic-width and contain-intrinsic-height into account.
The WritingMode parameter is replaced with a nsIFrame from which the
properties are retrieved.
There are various places that aren't currently using these functions, so
the effect of this patch is rather minimal, but some cases of the new
test are now passing.
Differential Revision: https://phabricator.services.mozilla.com/D152355
This patch introduces animation-composition longhand but we don't
accept it in @keyframe rule for now. I will support this for @keyframe
in the patch series.
Besides, the shorthand of animation doesn't include animation-composition.
The spec issue is: https://github.com/w3c/csswg-drafts/issues/6946.
We could fix the shorthand once this spec issue gets updated.
Differential Revision: https://phabricator.services.mozilla.com/D150299
This patch does not change behavior; it's just a const-correctness fix.
This patch was prompted by the desire to add "const" to a ComputedStyle*
variable in a place where we happen to call DetermineBackgroundColor. To do
that, I have to adjust DetermineBackgroundColor to accept a const arg; and that
in turn requires GetBackgroundColor to accept a const arg, which in turn
requires IsTransparent to require a const arg. Hence, fixing all three APIs
here.
I'll opportunistically add 'const' labels at callsites for these APIs in the
next patch in this series.
Differential Revision: https://phabricator.services.mozilla.com/D149674
Don't generate the button if the combobox doesn't need it anyways (if the
appearance is not menulist).
While at it improve the code that reframes on appearance: textfield changes so
that it only applies to number inputs as it should.
This shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D145712
This mostly just moves code around, to minimize potential behavior
changes. There are some cleanups that we should try to do long term
(this "have an array with n different counts" is pretty weird).
But for now this should unblock people.
The destination struct (nsStyleUIReset) was chosen mainly because it's
small and non-inherited, and it doesn't seem like a worse place than
nsStyleDisplay.
Differential Revision: https://phabricator.services.mozilla.com/D144183
The reason these used to have to reconstruct the frame was so that we called nsPresContext::UpdateViewportScrollStylesOverride to update nsPresContext::mViewportScrollStyles. That field used to store scroll behavior and scroll snap data, it no longer does.
In the current code mScrollBehavior is only checked here https://searchfox.org/mozilla-central/rev/d34f9713ae128a3138c2b70d8041a535f1049d19/layout/generic/nsGfxScrollFrame.cpp#8111 before we perform a new scroll, so no change is needed, any future scroll operation will look in the correct place.
scroll-snap-type is similar except we also store it on the FrameMetrics we send to the compositor so we need to repaint.
Note that even currently where we reconstruct the frame on scroll-snap-type changes we do not perform snapping if we move from none to mandatory or proximity, this is bug 1530253. So by removing the frame reconstruct we are not regressing that since we currently fail to do it.
Differential Revision: https://phabricator.services.mozilla.com/D143690
Two noteworthy details that may seem random otherwise:
* Moving values around in nsStyleDisplay is needed so that the struct
remains under the size limit that we have to avoid jumping allocator
buckets.
* All the test expectation churn is because tests depend on
`container-type: size` parsing to run, and now they run. Tests for
the relevant bits I implemented are passing, with the only exception
of some `container-name-computed.html` failures which are
https://github.com/w3c/csswg-drafts/issues/7181. Safari agrees with
us there.
Other notes when looking at the spec and seeing how it matches the
implementation:
* `container` syntax doesn't match spec, but matches tests and sanity:
https://github.com/w3c/csswg-drafts/issues/7180
* `container-type` syntax doesn't _quite_ match spec, but matches tests
and I think it's a spec bug since the definition for the missing
keyword is gone:
https://github.com/w3c/csswg-drafts/issues/7179
Differential Revision: https://phabricator.services.mozilla.com/D142419
Before this patch we might not update the ink overflow areas when
'outline-style' changes without changing outline-width, if
'outline-width' was zero.
This was triggered by TopLevelVideoDocument which had 'outline-width: 0'
which before bug 1759602 disabled the default outline.
The test reliably triggers the assertion (though I think we should try
to avoid the frame property in the common case the inner rect and frame
rects just match, which would remove the assertion...).
Differential Revision: https://phabricator.services.mozilla.com/D141320
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
