After LibJS had its symbol exports optimized the targets
js, test-js, test262-runner, test-wasm, and LibWeb began to get linker
errors after the work to add Windows support for test-web and ladybird
targets. These extra JS_API annotations fix all those linker errors.
Fixes bug when we didn't use `tracks_to_grow_beyond_limits` and instead
distributed extra space to all affected tracks. Also implements missing
"when accommodating max-content" part.
Instead of ignoring fields using forward-delcared types, always assume
they inherit from GC::Cell. This improves the worst case from a missed
unvisited field, to a slightly wrong error message.
Fixes#5959.
Our Color::to_premultiplied() and Color::to_unpremultiplied() used
integer truncation.
Apple’s Accelerate framework (and many other libraries) use
round-to-nearest, which avoids bias and produces results that differ
by ±1 in many cases.
This commit switches both helpers to round-to-nearest and clamps the
results to [0,255]. For alpha==0 we now return fully transparent black
(0,0,0,0) to align with common conventions, instead of preserving RGB.
We pass to-fixed-length-buffer.any.html and to-resizable-buffer.any.html
but not to-resizable-buffer-shared.any.html, because LibJS doesn't have
growable SharedArrayBuffers implemented...
This commit adds the toResizableBuffer() and toFixedLengthBuffer()
methods to WebAssembly.Memory. This includes the necessary hook to
HostResizeArrayBuffer. Some modifications to function signatures in
LibWeb/WebAssembly/Memory.h were also made (changing the return type
from WebIDL::ExceptionOr to JS::ThrowCompletionOr) to allow the use of
some code in the aforementioned hook.
Note: the hook for HostGrowSharedArrayBuffer isn't implemented, since
LibJS doesn't seem to have complete support for growable
SharedArrayBuffers; the relevant methods/getters don't even exist on
the prototype, let alone HostGrowSharedArrayBuffer!
This should help pass the WebAssembly.Memory WPT tests included in
Interop 2025, except those pertaining to growable SharedArrayBuffers.
If a memory is imported by a Wasm instance and re-exported, the export's
value should be the exact same WebAssembly.Memory object as the
WebAssembly.Memory object passed for the import.
This cache is referenced by a few parts of the JS API spec, including
the threads spec (such as in toFixedLengthBuffer), as well as the
"refresh the Memory buffer" algorithm, which was implemented as a method
of Memory before this change.
Now, this algorithm can be implemented in a spec-like fashion (though it
mostly seems to add extra complexity). This change also fixes a bug
where memories that were re-exported from an imported WebAssembly.Memory
were given a distinct WebAssembly.Memory object, since the caching that
existed in Instance.cpp was instance-local, not global to the realm.
We also make Memory::m_buffer non-lazy, since we have to implement
"initialize a memory object" correctly anyway.
The relevant type of ArrayBuffer DataBlock is now a struct containing
both a ByteBuffer* and a size_t size, and not just a ByteBuffer*, with
the size being that of the ByteBuffer. This type of DataBlock is only
used for WebAssembly.Memory (see commit 4fd43a8f96), meaning this
change won't affect any other code. This change is required to pass one
WPT subtest in wasm/jsapi/memory/grow.any.html, since old fixed-length
SharedArrayBuffers after a WebAssembly.Memory growth should keep their
length, while the new buffer after the growth will have the updated
length.
For whatever reason, the implementation of "create a fixed length memory
buffer" was borked for shared Wasm memories, in that a new
SharedArrayBuffer was created, with the contents of the Wasm memory
copied into it. This is incorrect, since the SharedArrayBuffer should be
a view into the Wasm memory's span, not a copy of it. This helps pass a
WPT subtest in wasm/jsapi/memory/grow.any.html.
Previously, clicking in the middle of a multi-code point grapheme would
place the cursor at a code unit index somewhere in the middle of the
grapheme. This was not only visually misleading, but the user could then
start typing and insert characters in the middle of the cluster. This
also made text select pretty wonky.
The main issue was that we were treating the glyph index in a glyph run
as a code unit index. We must instead map that glyph index back to a
code unit index with help from LibGfx (via harfbuzz).
The distance computation used here was also a bit off, especially for
the last glyph in a glyph run. We essentially want the cursor to end
up on whichever edge of the clicked glyph it is closest to. The result
of the distance computation limited us to the left edge of the last
glyph. Instead, we can use the same edge tracking we use for form-
associated elements to handle this for us.
We currently have a mixup in LibWeb between code unit offset and glyph
offset during hit testing. These extra fields will allow us to correct
this discrepency.
We were already using the XML parser for SVG files when opening at the
top level. This patch makes things consistent by using the same code
path when parsing SVG-as-image.
We also make some tweaks in SVG presentation attribute handling since
we can no longer rely on the HTML length attribute parsing quirk when
parsing width/height attributes.
