The `start` and `end` value set the text alignment based on the computed
value of `direction`. The default value of `text-align` is now `start`
instead of `left`.
(cherry picked from commit 1537d589ca4908c3631dc38e66c97fd37fa2f526)
Right now, we deviate from the CSSOM spec regarding our
CSSStyleDeclaration classes, so this is not as close to the spec as I'd
like. But it works, which means we'll be able to test pseudo-element
styling a lot more easily. :^)
(cherry picked from commit 14611de362d1d41429688dc02ffaf037a32e2e5d)
Pseudo-elements' style is only computed while building the layout tree.
This meant that previously, they would not have their style recomputed
in some cases. (Such as when :hover is applied to an ancestor.)
Now, when recomputing an element's style, we also return a full
invalidation if one or more pseudo-elements would exist either before or
after style recomputation.
This heuristic produces some false positives, but no false negatives.
Because pseudo-elements' style is computed during layout building, any
computation done here is then thrown away. So this approach minimises
the amount of wasted style computation. Plus it's simple, until we have
data on what approach would be faster.
This fixes the Acid2 nose becoming blue when the .nose div is hovered.
(cherry picked from commit 7daf5cdaff0fa1bba211ad40eadca5a0a52437ad)
Not every value in a StyleProperties will be non-null by the time we
perform `revert`, so let's make a specialized function for reverting a
property instead of using the path that requires the value to be
non-null.
(cherry picked from commit a10610a1cad56294089fc9457e713eb7083312cd)
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.
Previously, the order of data was incorrectly based on x_origin and
y_origin, which are meant for where on the screen the image should be
placed (TarGA is an image format meant for graphic cards), instead of
Image descriptor bits 4 and 5, which specify the direction.
This fixes a problem where tga files generated with magick would render
up-side-down.
The test images where created in GIMP, 4 simple 2x2 images
exported as .tga, no compression, origin: Bottom Left
square-bottom-left.tga:
Red, Green
Blue, Magenta
square-bottom-right.tga:
Green, Red
Magenta, Blue
square-top-left.tga:
Blue, Magenta
Red, Green
square-top-right.tga:
Magenta, Blue
Green, Red
then this script was ran:
```python
def update_tga_descriptor(file_path, top_to_bottom, left_to_right):
with open(file_path, 'r+b') as f:
header = f.read(18)
descriptor = header[17]
descriptor &= ~(1 << 4);
descriptor &= ~(1 << 5);
if left_to_right:
descriptor |= 1 << 4;
if top_to_bottom:
descriptor |= 1 << 5;
header = header[:17] + bytes([descriptor])
f.seek(0)
f.write(header)
update_tga_descriptor('square-bottom-left.tga', False, False)
update_tga_descriptor('square-bottom-right.tga', False, True)
update_tga_descriptor('square-top-left.tga', True, False)
update_tga_descriptor('square-top-right.tga', True, True)
```
C++ will jovially select the implicit conversion operator, even if it's
complete bogus, such as for unknown-size types or non-destructible
types. Therefore, all such conversions (which incur a copy) must
(unfortunately) be explicit so that non-copyable types continue to work.
The test case was generated by opening `modular_property_8.jxl` in
Krita, then changing the Color Profile to Apple RGB and then exporting
as PNG. Finally, the conversion to JPEGXL was made with:
`cjxl --container=0 --modular=1 -d 0 -e 9 file.png icc.jxl`
Note that, we can't use Krita to export a jxl as it always create a
container instead of a raw stream. Also, this needs an old version of
`cjxl` (I used 0.7), as more recent version reencode the ICC profile
using the JPEGXL's internal representation for color profile, which is
encoded differently.
- Use TRY_OR_FAIL() instead of MUST() in a few places
- Use for-each loop in two tests
- Use StringView literals instead of u8 arrays in a few places
No behavior change.
This fixes cases where fuzzy matching would return a better score for
a different pattern than a needle perfectly matching the haystack.
As an example, when searching for "fire" in emojis, "Fire Engine" would
have scored 168, while "Fire" was giving only 160.
This patch makes the latter have the best possible score.
They do happen in practice.
We might have to do more to do actual color conversions with
these profiles, but for now let's at least load them.
Fixes rendering of a few images in my thesis in LibPDF.
The images were created in OmniGraffle in 2008, then saved as
PDF, then converted to eps using LaTeX tooling.
Brings wow.apng from 1.2M to 606K, while reducing encoding time from
233 ms to 167 ms.
(For comparison, writing wow.webp currently takes 88ms and produces
a 255K file. The input wow.gif is 184K.)
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)
Adds additional padding to the end-side of the scrollable overflow
rectangle as necessary to enable a scroll position that satisfies
the requirements of `place-content: end` alignment.
(cherry picked from commit 963cf1c2c4e4b1cd482c41d6f673b7207bbcc067)
This commit adds a new test case which carries out the following steps:
* write() to a block of an ext2 file, verify the write() was successful
* read() the same block back, verify the read() was successful
* verify that the data from the read() is identical to the data that was
written in the write()
The test runs the above steps on the following blocks of an ext2 file:
* the first and last direct blocks
* the first and last singly indirect blocks
* the first and last doubly indirect blocks
* the first and last triply indirect blocks
(cherry picked from commit 75216182c9a04741b2f773eb2f26ceb7a96bfbba)
(cherry picked from commit 2a55ab13ef9c735a16674006a518c0e5acf7c88f)
Co-authored-by: Sam Atkins <atkinssj@serenityos.org>
These have a few rules that we didn't follow in most cases:
- CSS-wide keywords are not allowed. (inherit, initial, etc)
- `default` is not allowed.
- The above and any other disallowed identifiers must be tested
case-insensitively.
This introduces a `parse_custom_ident_value()` method, which takes a
list of disallowed identifier names, and handles the above rules.
(cherry picked from commit 6ae2b8c3d901d8a7255046a4517fddd8b0fa84c4)
This is an AudioNode representing the final audio destination and is
what the user will ultimately hear.
This node is used as one of the connecting nodes in athenacrisis.com
Add a placeholder for the interface without anything backing it for now.
(cherry picked from commit 5eb80b8697d458ea2b70112a995e066f64b37ca6)
This ensures that calling `element.classList.toString()` always
produces the correct value.
(cherry picked from commit ec1f7779cb16223dab0ef9f7bf875c3f7b5724a9)
Previously, when creating a HTML element with
`document.createElementNS()` we would convert the given local name to
lowercase before deciding which element type to return. We now no
longer perform this lower case conversion, so if an uppercase local
name is provided, an element of type `HTMLUnknownElement` will be
returned. This aligns our implementation with the specification.
(cherry picked from commit 5a796629c61221261c1856e19dd829973e6158f0)
These let you format counters' current values as strings for use in
generated content.
(cherry picked from commit 898e3bd89878ddb87df06e056031673dc770be2b)
These control the state of CSS counters.
Parsing code for `reversed(counter-name)` is implemented, but disabled
for now until we are able to resolve values for those.
(cherry picked from commit 017d6c3314d57d4e351764f328c1d25dbc9d033a)
This code previously only allocated enough space in
m_col_elements_by_index for 1 slot per column, meaning that columns
with a span > 1 would write off the end of it.
(cherry picked from commit 9e32c9329acd89d73eeff3494a5e728077962513)
...for images that don't use a color indexing transform.
For now, write the predictor transform unconditionally, and predict
every pixel as its left neighbor (that is, use predictor 1 everywhere).
This will grow a better heuristic in time, and eventually we might want
to use more than 1 of the 13 different predictor modes. But on average,
doing this unconditionally is better than not doing it unconditionally.
(Also, it's possible to disable this transform using `image`'s
`--webp-allowed-transforms` flag.)
Using the same benchmark as in #24819, this reduces the total size
of the test images further, from 88M to 69M (21.6%). It does increase
runtime for compressing all these images from about 4.4s to 4.7s,
a 6.8% slowdown.
For the usual test image (no effect on the two animations, which use
the color indexing transform):
sunset_retro.png (876K):
1.2M -> 730K, 31.4 ms ± 0.8 ms -> 31.4 ms ± 0.7 ms
From 37% larger than the input to 16% _smaller_ than the input :^)
(A 39% size reduction for this image.)
Compressing sunset_retro.png with zopflipng produces a 820K image,
so we're smaller even than what the best PNG encoder can do with
this image.
It's not a win for all images: For example, the size of
qoi_benchmark_suite/screenshot_web/sublime.png goes from 1.0M to 1.5M,
a fairly dramatic size increase. Hopefully we can get that back in
the future with better heuristics. (The input sublime.png is 1.3M,
and sublime.png encoded using our QOI encoder creates a 1.6M file,
so the 1.5M isn't atrocious, even though it's much bigger than the
size without the predictor transform.)
Our WebP Lossless writer currently now has a similar feature set
to our QOI writer: RLE, color cache, left prediction, and
subtract green is somewhat similar to QOI's luma chunk. The WebP
writer also writes huffman trees, which QOI doesn't do. For most
images, the WebP writer creates smaller files than the QOI writer,
while being about 50% slower. The WebP writer also writes smaller
files than Serenity OS's png writer, while being ~40x as fast
(for sunset_retro, ~30ms instead of ~1.3s; 730K output instead of
999K).
Only doing RLE and using a single predictor for the entire image is
similar to what fpng is doing (...but fpng uses the T predictor always).
We still don't write a meta prefix image to keep the huffman trees
flatter, we still don't do full LZ77 backward matches, and we still
don't write color transforms. But the writer has now enough features
to be in usable shape. It's now Serenity OS's best-compressing lossless
image writer.
The test_webp_color_indexing_transform_single_channel test uses a
linear horizontal gradient, which the predictor transform compresses
so well that encoded_data_without_color_indexing ends up being
smaller than the color indexed file. Just disable the predictor
transform in that test for now.
Removes some noise from the console when browsing bbc.co.uk :^)
(cherry picked from commit 793248aec977d4b15006d6e55a960da2e115a734,
amended to s/UIEvents::KeyCode/KeyCode/ to resolve cherry-pick conflict)
We now ensure that `Node::is_character_data()` returns true for all
nodes of type character data.
Previously, calling `Node::length()` on `CDataSection` or
`ProcessingInstruction` nodes would return an incorrect value.
(cherry picked from commit 3802d9ccc4ea4428b82c6d584c3667c040cb46c7)
We now follow the rules from the spec more closely, along with an
unspecified quirk for when the offsetParent is a non-positioned body
element. (Spec bug linked in a comment.)
This fixes a whole bunch of css-flexbox tests on WPT, which already had
correct layout, but the reported metrics from JS API were wrong.
(cherry picked from commit d49ae5af32044cb83bc14073b92676a1662c3bc1)