This was a cache race condition between the fuzzers and sanitizer
builds, where the vcpkg binary cache could have been updated before the
sanitizer builds started doing their vcpkg install, causing the source
assets to never be updated at all.
Previously, an SVG with width of zero would have am intrinsic aspect
ratio of zero. With this change, if an SVG has a width or height of
zero, the intrinsic aspect ratio is determined by the SVG's viewbox.
...for `text-justify: inter-character`.
We previously had this mapped in Enums.json, but the behaviour is
different: `a=b` in Enums.json keeps `a` around but makes it behave the
same as `b`. A legacy name alias is instead expected to replace `a`
with `b`, so we have to do that separately.
We don't yet have a system for "legacy value aliases", but until we have
a lot of them we can handle them manually.
We also have to do this in two places because
parse_css_value_for_property() doesn't call any property-specific
parsing code.
Before this change we were running the CSS cascade machinery twice per
element:
- First, to compute the "logical alias mapping context" based on
writing-mode and pals.
- Then, to compute all properties.
This patch factors out the heaviest work from the cascade machinery
to a separate step that can be run only once. This step will:
- Collect all the matching rules for the element
- Resolve custom properties for the element
We still perform the per-element cascade twice, but now this is hogging
less than 1% of CPU time when typing on Discord (compared to 9% before.)
The specification [1] indicates that the tentative used width and height
should be computed first, and if they exceed the `max-width` or
`max-height`, the rules should be applied again using the computed
values of `max-width` and `max-height`.
The only required change to follow the spec is to remove the early
`return` statements, in both `compute_width_for_replaced_element`
and `compute_height_for_replaced_element`.
Fixes#5100.
[1] https://www.w3.org/TR/CSS22/visudet.html#min-max-widths
To make {,de}serialization of ImageBitmap work we also had to add
support for creating an ImageBitmap from a HTMLCanvasElement in
WindowOrWorkerGlobalScopeMixin::create_image_bitmap_impl().
This refactors out the reading part of Gfx::Bitmap from
HtmlCanvasElement::surface(). We can then reuse this from
WindowOrWorkerGlobalScopeMixin::create_image_bitmap_impl() when we
create an ImageBitmap from a HtmlCanvasElement.
1. Fix typos in some macro invocations of these error types. We now use
a single xmacro to instantiate error definitions to prevent such
errors in the future.
2. Use the "WebAssembly." prefix as needed.
3. Allocate the error constructors and prototypes with `realm.create`
rather than `heap.allocate`. The latter does not invoke `initialize`
methods. This exposed the next issue:
4. Use the correct intrinsic prototype in the error constructor. We were
using the base native error prototype. We unfortunately cannot invoke
OrdinaryCreateFromConstructor from LibJS directly with the correct
prototype, so an implementation was added here.
5. Use intrinsic accessors to create the constructors. I don't think
this one was actually a fix, but it makes the setup look more like
other built-ins.
This fixes an issue where only the last KeyframeEffect applied to an
element would actually have an effect on the computed properties.
It was particularly noticeable when animating a shorthand property like
border-width, since only one of the border edges would have its width
actually animate.
By deferring the invalidation until all animations have been processed,
we also reduce the amount of work that gets done on pages with many
animations/transitions per element. Discord is very fond of this for
example.
Using the new hooks in the XML Parser's listener interface, we now
append DOM nodes for CDATASections and ProcessingInstructions
to the document as they are encountered. This commit also fixes where
comment nodes are appended, ensuring they are added to the current node
instead of the document root.
This allows listeners to be notified when a CDATASection or
ProcessingInstruction is encountered during parsing. The non-listener
path still has the incorrect behavior of silently treating CDATASection
as Text nodes, but this allows listeners to handle them correctly.
...elements. Adds missing pseudo-element type passed into computed
properties getter.
Previously, due to this bug, we were using the element's computed
properties as the previous computed properties for its pseudo-elements.
This caused an excessive number of unintended CSS transitions to run.
The issue was particularly noticeable in Discord's emoji picker, where
each emoji has `::after` pseudo-element. We were incorrectly triggering
transitions on all their properties, resulting in significant
unnecessary work in style computation and animation event dispatching.
...and setter. We had lots of places where we check if pseudo-element
type is specified and then use `pseudo_element_computed_properties()` or
`computed_properties()`. This change moves these checks from caller side
to the getter and setter.
Utf16FlyString more or less works exactly the same as FlyString. It will
store the raw encoded data of the string instance. If the string is a
short ASCII string, Utf16FlyString holds the ShortString bytes; else,
Utf16FlyString holds a pointer to the Utf16StringData.
The underlying storage used during string formatting is StringBuilder.
To support UTF-16 strings, this patch allows callers to specify a mode
during StringBuilder construction. The default mode is UTF-8, for which
StringBuilder remains unchanged.
In UTF-16 mode, we treat the StringBuilder's internal ByteBuffer as a
series of u16 code units. Appending a single character will append 2
bytes for that character (cast to a char16_t). Appending a StringView
will transcode the string to UTF-16.
Utf16String also gains the same memory optimization that we added for
String, where we hand-off the underlying buffer to Utf16String to avoid
having to re-allocate.
In the future, we may want to further optimize for ASCII strings. For
example, we could defer committing to the u16-esque storage until we
see a non-ASCII code point.
This is a strictly UTF-16 string with some optimizations for ASCII.
* If created from a short UTF-8 or UTF-16 string that is also ASCII,
then the string is stored in an inlined byte buffer.
* If created with a long UTF-8 or UTF-16 string that is also ASCII,
then the string is stored in an outlined char buffer.
* If created with a short or long UTF-8 or UTF-16 string that is not
ASCII, then the string is stored in an outlined char16 buffer.
We do not store short non-ASCII text in the inlined buffer to avoid
confusion with operations such as `length_in_code_units` and
`code_unit_at`. For example, "😀" would be stored as 4 UTF-8 bytes
in short string form. But we still want `length_in_code_units` to
be 2, and `code_unit_at(0)` to be 0xD83D.
This was a mistake. Consider U+201C (LEFT DOUBLE QUOTATION MARK). This
code point is encoded as the bytes 0x1c 0x20 in UTF-16LE. Both of these
bytes are ASCII if interpreted as UTF-8. But the string itself is most
certainly not ASCII.
We now do the proper thing in terms of:
- Allowing percentages
- Returning the computed value in getComputedStyle
- Handling values out of the [0,1] range
Gains us 13 WPT passes in the imported tests.
