...in HTMLCanvasElement::to_data_url() and HTMLCanvasElement::to_blob().
This fixes the problem when surface is not allocated because context is
not initialized yet, even though canvas size is non-zero.
Fixes broken WebDriver screenshot endpoint.
For now only macOS is supported.
IOSurface is used as a backing store because it will allow us to read
it from Skia and write to it from OpenGL without any extra copying:
- ANGLE_metal_texture_client_buffer extension is used to create
EGLSurface from IOSurface.
- Then the same IOSurface is wrapped into Metal texture and passed to
Skia allowing to share the same memory between Skia Metal backend and
ANGLE.
Previously, constructing a PaintingSurface from an IOSurface required
wrapping IOSurface into a Metal texture before passing it to the
PaintingSurface constructor. This process was cumbersome, as the caller
needed access to a MetalContext to perform the wrapping.
With this change SkiaBackendContext maintains a reference to the
MetalContext which makes it possible to do:
IOSurface -> MetalTexture -> SkSurface within a PaintingSurface
constructor.
Implement transfer logic for ArrayBuffer and ResizableArrayBuffer.
Change TransferDataHolder data type to Vector<u32> to reuse existing
serialization infrastructure.
Fix 5 WPT tests in `window-postmessage.window.html` that relates to
transport.
Fix `LibWeb/Text/input/Worker/Worker-postMessage-transfer.html`.
The latter is currently ignored due to flakiness, no rebaseline is
needed.
During serialization with transfer, initialize memory with known index
and initialize Serializer at position that dependent on the memory.
This is mandatory to make ArrayBuffer transport to work. It also happens
to fix 4 WPT tests, that are related to curcular references during
serialization.
The 'reason' was getting initialized to 'empty' state when not
provided through the constructor, which results in a crash when
accessed through throw_dom_exception_if_needed in the generated
IDL getter.
All global objects current need to be event targets so that they
can have events dispatched to them. This allows for removing of
verify_cast for these global objects.
The rules for parsing integers don't specify an upper bound on the
value that can be returned, so the `parse_integer_digits` method can be
used to check whether the given arbitrarily-large StringView is valid
according to these rules. The `parse_integer` and
`parse_non_negative_integer` methods would fail for values larger than
2147483647 when they shouldn't have.
Setting the `width` or `height` properties of `HTMLCanvasElement` to a
value greater than 2147483647 will now cause the property to be set to
its default value.
Lazily coercing might have made sense in the past, but since hashing
and comparing requires the `PropertyKey` to be coerced, and since a
`PropertyKey` will be used to index into a hashmap 99% of the time,
which will hash the `PropertyKey` and use it in comparisons, the
extra complexity and branching produced by lazily coercing has
become more trouble than it is worth.
Remove the lazy coercions, which then also neatly allows us to
switch to a `Variant`-based implementation.
Corresponds to https://github.com/whatwg/html/pull/10683
As part of this, I noticed we incorrectly were setting the "is popup"
flag on the Navigable instead of the BrowsingContext. I've fixed that
and removed the erroneous flag from Navigable.
This lets us move a few Host-related functions (like serialization and
checks for what the Host is) into Host instead of having them dotted
around the codebase.
For now, the interface is still very Variant-like, to avoid having to
change quite so much in one go.
A couple of reasons:
- Origin's Host (when in the tuple state) can't be null
- There's an "empty host" concept in the spec which is NOT the same as a
null Host, and that was confusing me.
There was a bug in the HTML proposal where a synthetic realm settings
object's principal realm was a shadow realm if there were nested shadow
realms, which this assertion catches more directly (rather than later
down the track, where it is used).
We were meant to also assert for this case, but we were previously
returning early.
When attempting to set `HTMLProgressElement.max` to a value not greater
than 0, we were previously setting the value to 1. We now retain the
previous value.
This change ensures that the correct default value of 0 is used and
that values greater than 2147483647 will fall back to the default value.
It also splits the display size concept into a separate method, as
this isn't supposed to be used when getting the IDL property.
