We only set the grapheme segmenter's text once after creating a new
segmenter, so we also need to clear it whenever we invalidate the text.
(cherry picked from commit 25516e351e46104ff445216e7835aaab9f9b9535)
These are created when a style rule has properties listed after another
rule. For example:
```css
.test {
--a: 1;
--b: 1;
--c: 1;
.thing {
/* ... */
}
/* These are after a rule (.thing) so they're wrapped in a
CSSNestedDeclarations: */
--d: 1;
--e: 1;
--f: 1;
}
```
They're treated like a nested style rule with the exact same selectors
as their containing style rule.
(cherry picked from commit e4245dc39e68d9376dfb2344c78119a938533319)
For example, this:
```css
.foo {
color: red;
&:hover {
color: green;
}
}
```
now has the same effect as this:
```css
.foo {
color: red;
}
.foo:hover {
color: green;
}
```
CSSStyleRule now has "absolutized selectors", which are its selectors
with any `&`s resolved. We use these instead of the "real" selectors
when matching them, meaning the style computer doesn't have to know or
care about where the selector appears in the CSS document.
(cherry picked from commit 53f99e51f8382a20cec7752480d505957a2680b1)
We *could* even skip creating a paintable for hidden nodes, but that
means that dynamic updates to the CSS visibility property would require
mutating the paint tree, so let's keep it simple for now.
(cherry picked from commit 349b17cc7aaba8c6cce3aaef26d14a0127f43ff1)
Example of the difference:
50 * 2.55 --> 127.4999 --> round towards +∞ --> 127
50 * 255 / 100 --> 127.5000 --> round towards +∞ --> 128
Now, 9 failing WPT tests in /css/css-color/ pass.
(cherry picked from commit 6c3ecf6a342cbc0a83c1deac89e1a7edf6d959c4;
amended because css-color-functions.html is a reftest for us, not
a screenshot test)
Instead of CSSColorValue holding a Gfx::Color, make it an abstract class
with subclasses for each different color function, to match the Typed-OM
spec. This means moving the color calculations from the parsing code to
the `to_color()` method on the style value.
This lets us have calc() inside a color function, instead of having to
fully resolve the color at parse time. The canvas fillStyle tests have
been updated to reflect this.
The other test change is Screenshot/css-color-functions.html: previously
we produced slightly different colors for an alpha of 0.5 and one of
50%, and this incorrect behavior was baked into the test. So now it's
more correct. :^)
(cherry picked from commit 3af6a69f1e13803c64466a9b24b7bd7d75d459df;
amended to:
* resolve a minor conflict in Parser.cpp due to upstream not having
https://github.com/LadybirdBrowser/ladybird/pull/385#issuecomment-2227130015
* rebaseline canvas-fillstyle-rgb.png since the diff didn't apply due to
us not having https://github.com/LadybirdBrowser/ladybird/pull/999
* remove css-color-functions-ref.png and instead update
css-color-functions-ref.html since that file is still a reftest due to us
not having https://github.com/LadybirdBrowser/ladybird/pull/736
Makes it much easier to see what actually changed.
)
This change will make it easier to disable screenshot comparison tests
on a specific platform or have per-platform expectations.
Additionally, it's nice to be able to tell if a ref-test uses a
screenshot as an expectation by looking at the test path.
(cherry picked from commit 715f0330070d9f8ecc88a8e66e4d8c85f795d622;
amended to also move
Tests/LibWeb/Screenshot/canvas-stroke-styles.html and support files)
A stroked path that has the same start and end point looks different
depending on if it's closed or not: If it's closed, the start/end point
is drawn as a line join; if it's not closed, the start/end point is
drawn as a cap.
(It has an effect only for stroked paths, but not for filled paths.)
So make Path remember if it's closed or not by adding a ClosePath
segment type.
This matches the canvas, pdf, svg specs.
(TinyVG doesn't have strokes yet.)
This fixes the apparent rendering regression from #25040 / #25044
(which just made an existing bug visible).
(We should probably make an inner and an outer path when stroking a
closed path instead of just giving closed paths a round cap. When
filled, both look identical, but the current approach produces more
geometry. For now, this is good enough.)
To rebaseline image test expecatations, I ran:
out/gn/Ladybird.app/Contents/MacOS/headless-browser \
--resources $PWD/out/gn/Ladybird.app/Contents/Resources \
--dump-failed-ref-tests \
--run-tests $PWD/Tests/LibWeb \
--filter 'canvas-*'
I then copied over the new baselines with
D=Tests/LibWeb/Ref/reference/images
cp test-dumps/canvas-implict-moves-and-lines.png \
$D/canvas-implict-moves-and-lines-ref.png
(Note: No `-ref` suffix on first path, yes suffix on second path.)
We currently don't track if a path is open or closed, and paint
butt linecaps at the end of closed paths too. We did that with
round linecaps as well, but there that wasn't visible. This makes
closed paths look a bit weird now; we'll have to fix this in a
follow-up. In a way, this just exposes another not-yet-implemented
feature.
On macOS, when going from the right end of a horizontal line
to the left, and when slope_now is pi, and the current
range.end is 0 (i.e. current_angle = pi, target_angle = 0),
clockwise() would set target_angle to 2 * pi, and
`target_angle - current_angle` (ie 2 * pi - pi) would end up
being ever so sligthly more than `pi` (handwavingly due to
floating point in accuracies), and we'd go in the wrong direction.
Add an explicit check for that, and a reftest that catches this.
No observed behavior change on linux, but the reftest only passes
on macOS with the code change.
Moves paint_table_borders() call into PaintableBox::paint() to make
scroll offset and clip rectangle of enclosing scrollable be applied
in ::before_paint().
(cherry picked from commit 2cc2646f5585e4a1f617ac809806bf05e8e515a4)
The main intention of this change is to have a consistent look and
behavior across all scrollbars, including elements with
`overflow: scroll` and `overflow: auto`, iframes, and a page.
Before:
- Page's scrollbar is painted by Browser (Qt/AppKit) using the
corresponding UI framework style,
- Both WebContent and Browser know the scroll position offset.
- WebContent uses did_request_scroll_to() IPC call to send updates.
- Browser uses set_viewport_rect() to send updates.
After:
- Page's scrollbar is painted on WebContent side using the same style as
currently used for elements with `overflow: scroll` and
`overflow: auto`. A nice side effects: scrollbars are now painted for
iframes, and page's scrollbar respects scrollbar-width CSS property.
- Only WebContent knows scroll position offset.
- did_request_scroll_to() is no longer used.
- set_viewport_rect() is changed to set_viewport_size().
(cherry picked from commit 5285e22f2aa09152365179865f135e7bc5d254a5)
Co-authored-by: Jamie Mansfield <jmansfield@cadixdev.org>
Co-authored-by: Nico Weber <thakis@chromium.org>
`Painting::paint_all_borders()` only uses `.draw_line()` for simple
borders and `.fill_path()` for more complex cases. These are both
already supported by the `RecordingPainter` so removing this command
simplifies the painting API.
Two test changes:
css-background-clip-text: Borders are now drawn via the AA painter
(which makes them closer to how they appear in other browsers).
corner-clip-inside-scrollable: Borders removed (does not change test)
due to imperceptible sub-pixel changes.
All painting commands except SetClipRect are shifted by scroll offset
before command list execution. This change removes scroll offset
translation for sample/blit corner commands in
`PaintableWithLines::paint` so it is only applied once in
`CommandList::apply_scroll_offsets()`.
Fixes bug when CSS transform is applied twice to clip rect:
- While calculating absolute clip rectangles in `refresh_clip_state()`
- While executing `PushStackingContext` painting command.
Duplicated transform is already removed for PaintableBox and this change
adds this for InlinePaintable.
PaintFrame is not primitive painting command, we inherited from OS, that
is hard to replicate in GPU-painter or alternative CPU-painter API. We
should remove it as a part of refactoring towards simplifying recording
painter commands set.
Fixes: #23796
Going via the `ViewportPaintable` missed some steps (in particular
computing clip rects), which meant nested SVGs within SVGs-as-images
were completely clipped.
If an unexpected token is encountered when parsing an SVG attribute it
is now immediately propagated with ErrorOr. Previously, some situations
where an unexpected token was encountered could cause a crash.
