An upcoming commit will migrate the contents of Headers.h/cpp to LibHTTP
for use outside of LibWeb. These CORS and MIME helpers depend on other
LibWeb facilities, however, so they cannot be moved.
We were always rendering <symbol> SVG elements, but we should only
render them if they are a child of a <use>'s shadow root. This caused
practically all instances of <symbol> to be drawn at least one time too
many.
Previously, we only supported very basic numbers and a single level of
text positioning support in the `x`, `y`, `dx` and `dy` attributes in
`<text>` and `<tspan>` SVG elements.
This improves our support for them in the following ways:
* Any `length-percentage` or `number` type value is accepted;
* Nested `<text>` and `<tspan>` use the 'current text position'
concept to determine where the next text run should go;
* We expose the attributes' values through the API.
Though we still do not support:
* Applying the `rotate` attribute;
* Applying transformations on a per-character basis.
* Proper horizontal and vertical glyph advancing (we just use the path
bounding box for now).
We have a couple of ways to designate spec notes and (our) developer
notes in comments, but we never really settled on a single approach. As
a result, we have a bit of a mixed bag of note comments on our hands.
To the extent that I could find them, I changed developer notes to
`// NB: ...` and changed spec notes to `// NOTE: ...`. The rationale for
this is that in most web specs, notes are prefixed by `NOTE: ...` so
this makes it easier to copy paste verbatim. The choice for `NB: ...` is
pretty arbitrary, but it makes it stand out from the regular spec notes
and it was already in wide use in our codebase.
We simplify these at style computation time so there is no need to
maintain them as {Number|Length}OrCalculated
Reduces the time spent in `Length::ResolutionContext::for_layout_node`
from 3.3% to 0.4% when loading
https://en.wikipedia.org/wiki/2023_in_American_television
The spec defines a generic list interfaces that we can reuse. Currently
we only have SVGTransformList, but we will need this to add
SVGNumberList as well.
Prevents observably calling Trusted Types, which can run arbitrary JS,
cause crashes due to use of MUST and allow arbitrary JS to modify
internal elements.
Instead of painting DecodedImageData by first asking it for a bitmap
and then painting that, this commit adds two new APIs:
- frame_rect(frame_index):
Gets the size of the animation frame at the given index.
- paint(context, ...):
Paints the DecodedImageData into a DisplayListRecordingContext.
The main powerful thing here is that this allows SVGDecodedImageData
to render itself using the GPU when available.
There's a fairly complicated interaction between an SVG gradient's paint
transformation and the gradient coordinate transformation required to
correctly draw gradient fills. This was especially noticeable when
scaling down an SVG, resulting in broken gradient coordinates and
graphical glitches.
This changes the objectBoundingBox units to immediately map to the
bounding box's coordinate system, so we can unify the gradient paint
transformation logic and make it a lot simpler. We only need to undo the
bounding box offset and apply the paint transformation to fix a lot of
gradient fill bugs.
We already had the API, but drawing to the canvas was not affected by
any created CanvasPattern. This moves CanvasPatternPaintStyle to LibGfx
so we don't have to reach into LibWeb, and implements the plumbing to
let Skia use images as a fill pattern.
Per SVG2 spec (ยง Geometry Properties: getBBox), getBBox() must throw
InvalidStateError if the element is not rendered and its geometry cannot
be computed. Previously we would crash on null paintables; now we throw
with a clear error instead.
Interpolation can leave `padding-*` values as negative - this should be
handled by interpolation clamping it to the allowed range of values
but we don't yet do that. As a stop gap we can clamp this before setting
it in ComputedValues.
This fixes 3 crashes and gains us 11 passes in the imported WPT tests
Currently, ImageProvider::current_image_bitmap takes a Gfx::IntSize
argument which determines the size of the returned bitmap. The default
value of this argument is 0x0 which causes the function to return
nullptr. This behavior is evidently unintuitive enough that it has lead
to incorrect usage in multiple places. For example, the 2D canvas
drawImage method will never actually draw anything because it calls
current_image_bitmap with no arguments. And the naturalWidth and
naturalHeight of an image will always return 0 (even after the image has
loaded) for the same reason.
To correct this and hopefully avoid similar issues in the future,
ImageProvider::current_image_bitmap will be renamed to
current_image_bitmap_sized, and the default value for the size argument
will be removed. For consistency, a similar change will be made to
SVGImageElement::default_image_bitmap.
The existing current_image_bitmap function will no longer take a size
argument. Instead it will always return a bitmap of the image's
intrinsic size. This seems to be what most existing callers had already
assumed was the function's behavior.
