This test captures the current (incorrect) behavior where setting
`overflow: hidden` on an SVG `<g>` element produces a clip in the
display list. Per the CSS Overflow spec, overflow properties only apply
to block containers, flex containers, and grid containers — not SVG
graphics elements.
This test verifies that SVG mask application on foreignObject is
preserved after partial SVG relayout. Currently the mask is not applied
to the foreignObject content after relayout because the stacking context
tree is not rebuilt.
When z-index changes from 0 to a positive value on a positioned element,
the stacking context tree is not rebuilt, causing the element to be
painted twice. This test captures the current (incorrect) behavior.
We don't have a text node in these, so no fragments either. Maintaining
a special case for this situation seems much simpler than reworking
`contenteditable`s to always have a fragment.
Our change to generate spans in PaintableWithLines from fragments also
broke drawing the caret for empty <input>s and <textarea>s, since spans
was empty in that case.
Fix this by moving caret drawing to PaintableWithLines, and only
invoking it if we have a cursor position set.
Previously, absolutely positioned elements jumped directly to their
containing block's accumulated visual context, skipping effects
(opacity, mix-blend-mode, isolation) from intermediate ancestors. Per
CSS spec, these properties create stacking contexts that abspos elements
cannot escape — they only escape scroll containers and overflow clips.
This test demonstrates an issue where TransformData/PerspectiveData can
be allocated twice for the same paintable box when a position:relative
element has an inline transformed ancestor.
This test verifies that modifying the CSS clip property via JavaScript
properly invalidates the accumulated visual context. Currently fails
because the clip rect in the display list remains unchanged after the
style update.
This test verifies that modifying clip-path via JavaScript properly
invalidates the accumulated visual context. Currently fails because the
clip-path in the display list remains unchanged after the style update.
Regression from 98afd82491.
When rounding a CSSPixelRect to a DevicePixelRect, we simply pulled its
width and height through round() and called it a day. Unfortunately this
could negatively affect the rect's perceived positioning.
A rect at { 0.5, 0.0 } with size { 19.5 x 20.0 } should have its right
edge at position 20, but after rounding it would end up at { 1, 0 } with
size { 20 x 20 }, causing its right edge to be at position 21 instead.
Fix this by first rounding the right and bottom edges of the input rect,
and then determining the dimensions by subtracting its rounded position.
Fixes#245.
There are some nuances to creating these wrappers, such as manually
propagating certain text styles that are not inherited by default. We
already have the logic for this in
`NodeWithStyle::create_anonymous_wrapper()`, so reuse that method in our
implementation of the button layout.
Fixes applying certain text styles (such as `text-decoration`) to the
text of a `<button>`.
It's useful to have tests that dump display list items, so we can more
easily see how changes to the display list recording process affect the
output. Even the small sample test added in this commit shows that we
currently record an unnecessary AddClipRect item for empty paint phases.
For now, the dump doesn't include every single property of an item, but
we can shape it to include more useful information as we iterate on it.
