In calculating the base size of a flex item, we have a piece of ad-hoc
code that deals with an item that does have an instrinsic aspect ratio,
but not a cross size to resolve that ratio against. In determining the
actual flex item size however, we also take into account the minimum
content width and height, which assumes the box' intrinsic width or
height when available. This would break having an image as a flex item,
which gets stretched to its maximum size within the flex container
instead of the flex item being shrunk to the instrinsic size of the
image.
Fix this by only stretching flex items that do not have an instrinsic
width nor height set.
Implements the corresponding encoders, selects the appropriate one when
encoding URL search params. If an encoder for the given encoding could
not be found, fallback to utf-8.
`m_needs_repaint = true` is not enough because it doesn't schedule
repaint of a parent navigable.
Fixes the bug when an iframe is not repainted after scrolling.
USVString is defined in the IDL spec as:
> The USVString type corresponds to scalar value strings. Depending on
> the context, these can be treated as sequences of either 16-bit
> unsigned integer code units or scalar values.
This means we need to account for surrogate code points by using the
replacement character.
This fixes the last test in https://wpt.live/url/url-constructor.any.html
When converting a `Gfx::Bitmap` to a Skia bitmap, we cannot assume the
color data is unpremultiplied. For example, everything canvas-related
uses premultiplied color data:
https://html.spec.whatwg.org/multipage/canvas.html#premultiplied-alpha-and-the-2d-rendering-context
We were probably assuming unpremultiplied since that is what the PNG
decoder gives us. Since we now make `Gfx::Bitmap` identify what alpha
type is being used, we can instruct Skia a bit better :^)
Update our `EdgeFlagPathRasterizer` to use premultiplied alpha instead
of unpremultiplied so we can apply alpha correctly for path masks.
This fixes the dark borders sometimes visible when SVGs are blended
with a colored background.
This also exposed an issue with our `CanvasRenderingContext2D`, which is
supposed to hold a bitmap with premultiplied alpha internally but expose
a bitmap with unpremultiplied alpha in `CanvasImageData`. Expand our C2D
test to include the alpha channel as well.
Finally, this also exposed an off-by-one issue in
`EdgeFlagPathRasterizer` which caused the last scanlines for edges to
render incorrectly. We had some reference images which included these
corruptions (they were almost unnoticeable), so update them as well.
We use instances of `Gfx::Bitmap` to move pixel data all the way from
raw image bytes up to the Skia renderer. A vital piece of information
for correct blending of bitmaps is the alpha type, i.e. are we dealing
with premultiplied or unpremultiplied color values?
Premultiplied means that the RGB colors have been multiplied with the
associated alpha value, i.e. RGB(255, 255, 255) with an alpha of 2% is
stored as RGBA(5, 5, 5, 2%).
Unpremultiplied means that the original RGB colors are stored,
regardless of the alpha value. I.e. RGB(255, 255, 255) with an alpha of
2% is stored as RGBA(255, 255, 255, 2%).
It is important to know how the color data is stored in a
`Gfx::Bitmap`, because correct blending depends on knowing the alpha
type: premultiplied blending uses `S + (1 - A) * D`, while
unpremultiplied blending uses `A * S + (1 - A) * D`.
This adds the alpha type information to `Gfx::Bitmap` across the board.
It isn't used anywhere yet.
Knowing whether pixel color data is premultiplied or unpremultiplied is
useful in more places; factor it out so we can use the enum elsewhere.
Implement support for premultiplied alpha in `Color::with_alpha()` and
`::set_alpha()`.
If a DOM node is an element with pseudo-elements, but it has no child
DOM nodes and is not a shadow host, then the code that serializes its
pseudo-elements would get skipped, making them not show up in the
inspector.
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. :^)
As noted, this is hacky because the parser wasn't written to allow
parsing an individual component of a selector. (Fox example, the
convenient-sounding `parse_pseudo_simple_selector()` assumes the first
colon has already been consumed...) So until that changes, this parses
the input as an entire selector-list, and then throws it away if it's
not a single pseudo-element selector.
It's only temporary though, I promise. 😅
The script pulls in a dependency on the `yaml` python package. Instead
of updating all the docs and CI jobs to account for this, let's guard
calling the script behind our experimental flag instead.
In theory the clang module map should not have absolute paths for the
headers. Other Swift projects seem to use the -ivfsoverlay feature of
clang to work around this, but it seems difficult to get to work.
And modernize the cmake_parse_arguments() call at the top.
Ideally, we would pull these flags from the target we're generating
for, but the current CMake setup makes that prohibitively infeasible.
