The CSS box-shadow property takes 2-4 properties that are `<length>`s,
those being:
- offset-x
- offset-y
- blur-radius
- spread-radius
Previously these were resolved directly to concrete Lengths at parse
time, but now they will be parsed as LengthStyleValues and/or
CalculatedStyleValues and be stored that way until styles are later
resolved.
The used width is already a content width, which doesn't include
borders. Border widths should be subtracted from the specified width
instead, since that initially specifies the total width including
borders, for consistent comparison. Also handle table box padding as an
additional fix.
There are hundreds of test262 tests with the following metadata line:
flags: []
Other engine runners are apparently able to ignore those lines, so we
should as well.
On style update, we have to preserve the invariant established when we
built the layout tree - some properties are applied to the table wrapper
and the table box values are reset to their initial values.
This also ensures that the containing block of a table box is always a
table wrapper, which isn't the case if we set absolute position on the
box instead of the wrapper.
Fixes#19452.
The JS::VM now owns the one Bytecode::Interpreter. We no longer have
multiple bytecode interpreters, and there is no concept of a "current"
bytecode interpreter.
If you ask for VM::bytecode_interpreter_if_exists(), it will return null
if we're not running the program in "bytecode enabled" mode.
If you ask for VM::bytecode_interpreter(), it will return a bytecode
interpreter in all modes. This is used for situations where even the AST
interpreter switches to bytecode mode (generators, etc.)
This was meant to be a temporary unit testuntil we could run test-js
in bytecode mode. This has been possible for a long time now, so let's
remove the unnecessary extra program.
This fixes the issue when size of abspos items is considered to be
resolvable without performing layout which is not correct in the
scenarious when top/right/bottom/left properties are not auto.
Return error when input svg is not valid and SVGSVGElement is not
present in the tree instead of doing svg_root nullptr dereference.
Fixes crash on https://apps.kde.org/en-gb/
Adding undistributable space right before setting the content width is
incorrect when it's a percentage. Follow the specification and add it to
GRIDMIN and GRIDMAX instead.
In particular, in BFC:
- Non-floating, non-replaced elements
- Floating, non-replaced elements
- Floating, replaced elements
The first two regressed in 1d76126abe
The third one seems to have been introduced by this regression, as it
was seemingly copied from compute_width_for_floating_box in
7f9ede07bc
The fix here has two parts:
1. Don't use the fallback viewBox at all if we're not in SVG-as-image.
2. Don't make a fallback viewBox with zero width and/or height.
This fixes a crash on Bandcamp pages. Thanks Tim Flynn for reporting!
The shortcut we put in place didn't resolve percentage widths and
ignored border spacing. We can still return early after we compute the
width per the specifications.
While CSS 2.2 does tell us to use the "auto height for BFC roots"
calculation when resolving auto heights for abspos elements, that
doesn't make sense for other formatting context roots, e.g flex.
In lieu of implementing the entire new absolute positioning model from
CSS-POSITION-3, this patch borrows one small nugget from it: using
fit-content height as the auto height for non-BFC-root abspos elements.
This just works at the moment after e19892a099, but if we ever do
the FIXME in ColorIndexingTransform::transform(), this test will
remind us to think of this case there too.
catdog-alert-13-alpha-used-false.webp is identical to
catdog-alert-13.web but with the byte at offset 0x2a changed from
0x10 to 0x00 -- that is, the bit in the VP8L header that stores
`is_alpha_used` is cleared.
See the commit message of e19892a099 for more information.
When embedding an SVG in an img element, if the external SVG's root
element has both width and height attributes, but no viewBox attribute,
we now create a fallback viewBox with "0 0 width height".
This appears to match the behavior of other browsers. Inspired by
discussion on Mozilla's bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=614649
If we don't paint, SVG-as-image documents don't get laid out, and so
have 0x0 size throughout.
This change is also generally nice, as it makes the painting code run
on all the layout tests, increasing coverage. :^)
Compute the contributions to a spanning cell width from each cell in the
span. This better handles uneven column widths, since each cell
contribution is proportional with its own width as opposed to the own
width of the first cell in the span.
This better matches the behavior of other browsers and further aligns
with the specification.
The part in FFC where we ask the parent formatting context to size the
flex container midway through layout is really weird, but let's at least
be consistently weird for BFC and IFC. Since IFC always works within its
parent BFC, it can simply forward these requests to the BFC.
This fixes an issue where inline-flex containers incorrectly had main
axis margins subtracted from their content size.
Two files are used both as test inputs for the webp decoder test and
for the icc profile test.
Use redundant copies of these two files for the two usecases, since
different parts of the files are used in both tests (and we could
remove the unneeded parts later).
With multi-line text cells, we don't reliably know the height would stay
the same as the one set by the independent format context run. In such
situations, we can end up with a table box which is sized inconsistently
with the grid boxes of the table due to differences in line breaks.
simple-vp8l-alpha-used-false.webp is a copy of simple-vp8l.webp,
with the byte at offset 0x18 changed from 0x10 to 0x00 -- that
is, the bit in the VP8L header that stores `is_alpha_used` is cleared.
We would already allocated a BGRx8888 instead of a BGRA8888 bitmap,
but keep actual alpha data in the `x` channel.
That lead to at least `image` still writing a PNG with an alpha channel.
So explicitly set the alpha channel to 0xff when is_alpha_used is false,
to make sure all consumers of decoded lossless webp data have behavior
consistent with other webp readers.
In practice, webp encoders usually don't write files that have
`is_alpha_used` set to false and then write actual alpha data to their
output. So this is rarely observable. However, for example for
lossy+ALPH webp files, the lossless webp used to store the ALPH channel
has `is_alpha_used` set to false and all channels but green are 0
(since the lossless green channel stores the alpha channel of a
lossy+ALPH webp). So if we dump such a bitmap to a standalone webp
file (e.g. with the temporary debugging code in fc3249a1ca),
then without this commit here, `image` would convert that webp to
a fully transparent webp, while other webp software would correctly
display the green image with opaque alpha.
I was debugging a different issue in Ladybird, and noticed that
completing relative file URLs with URL::complete_url didn't seem to work
right. This test case covers both the working https case, as well as the
file URL case fixed by the previous commit.
In compute_table_box_width_inside_table_wrapper, we should only consider
available_width when it's valid. Values which come from {min,
max}-content constraints aren't meaningful and shouldn't be considered
for the cap.
Absolutely positioned elements should have their percentage sizes
resolved against the padding box of the containing block, not the
content box.
From CSS-POSITION-3 <https://www.w3.org/TR/css-position-3/#def-cb>
"..the containing block is formed by the padding edge of the ancestor.."
