And treat them as "auto" for now, per CSS-SIZING-3, with a FIXME about
supporting more layout directions.
This fixes an issue on MDN where `height: max-content` was not
overriding height from non-CSS presentational hints.
CSS-ALIGN-3 tells us that `normal` behavior inside flex containers is
simply to behave as `stretch` so this patch makes them behave the same
inside FFC.
Furthermore, we change the `align-items` initial value to `normal`,
matching other engines.
I'm about to make StackingContext traverse the paintable tree instead of
actually traversing the layout tree, and it turns out we were not
creating paintables for these SVG elements.
Also switch them to Layout::Box instead of the default InlineNode to
make the trees look a bit less weird. Ultimately, we should do something
specialized for these subtrees, but for now this'll do.
This patch just adds the new root paintable and updates the tests
expectations. The next patch will move painting logic from the layout
viewport to the paint viewport.
Instead of assuming that the WebDriver binary is in PATH or the two
most common build directories for our scripts, add a command line
argument to the script to pass a WebDriver binary.
We should be documenting required pacakges elsewhere and installing them
in the setup step of CI.
This also fixes a problem where the run script would fail if you already
had a cloned wpt directory.
The setup is a bit peculiar: both the definition and the use site of
these TLS variables have to be in a shared library, otherwise the linker
might relax the global-dynamic access mode to something that doesn't
require a `__tls_get_addr` call.
This has to cheat and use a screenshot but thanks to the "Take Full
Screenshot" feature of Ladybird, it is very easy to update this test.
The steps are documented in the test.
When a box is sized under max-content constraint, any percentage value
set for max-width should be considered as if it were infinite. In other
words, it should have no effect on restricting the box's width.
This doesn't seem to actually have fixed any bugs, as having
FillOpacity instead of StrokeOpacity in the call to parse_css_value
doesn't seem to have actually been causing bugs. But, I still think it's
worthwhile correcting.
The reason that it wasn't causing bugs is that having FillOpacity
instead of StrokeOpacity in the call to parse_css_value means that when
parsing the value is compared to the acceptable values for that property
(for example the value can only be a percentage, or a number, etc.). In
this case both FillOpacity and StrokeOpacity seem to accept the same
values.
The SVG G container should have the same size as its children. This
fixes a bug when there was an opacity value on the G element, as in
StackingContext it would try and get a bitmap of the element which would
be empty due to it having no size.
We now keep the color value as a StyleValue up until we go to paint the
gradient, which makes `currentColor` work, along with any other color
values that can't be immediately converted into a `Gfx::Color` while
parsing.
If we run an inline script from the HTML parser, it may append a text
node to the current insertion point.
If there was text content immediately following the script element,
we would previously overwrite the script-inserted text content, due to
an oversight in the way we select an appropriate insertion point
This patch fixes the issue by only inserting parser content into
existing text nodes if they are empty.
Instead of applying relative offsets (like position:relative insets)
during painting and hit testing, we now do a pass at the end of layout
and assign the final resolved offsets to paintables.
This makes painting and hit testing easier since they don't have to
think about relative offsets, and it also fixes a bug where offsets were
not applied to text fragments inside inline-flow elements that were
themselves position:relative.
The ref tests runner takes screenshots of both the input page and the
expected page, then compares them. Ref testing allows us to catch
painting bugs, which cannot be detected with the layout and text tests
we already have.
With ref tests, we'll likely want to reuse the same expectation page
for multiple inputs. Therefore, there's a `manifest.json` file that
describes the relationship between inputs and expected outputs.
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
Just like with input buffered streams, we don't currently have a use
case for output buffered streams which aren't seekable, since the main
application are files.
