We were delaying sending an IPC message until the HTML PortMessage
task was run, but we were not queuing the task in on the receiver
side. The result of this was that message port posting was
needlessly creating an HTML task just to send an IPC message.
On the flip side, we were directly calling dispatch_event from the
socket notifier of the target port's message queue. This is a huge
problem, because it means that we were effectively running
javascript-aware code from an 'in parallel' context.
By switching around which side of the IPC interface is responsible
for queuing a task, we can avoid problems where a document is
destroyed from a port message-attached callback and crashes.
The Gfx::Bitmap encoder and decoder have been replaced
by BitmapSequence in #1435, making them redundant and safe to remove.
Additionally, the base IPC::encode and IPC::decode implementations
will trigger a compiler error if these methods are called.
.ipc files already exclude references to Gfx::Bitmap.
This change fixes accessible-name computation for:
- an element that has empty text content but that also has a title
attribute (“tooltip”) with a non-empty value
- an img element whose alt attribute is the empty string but that also
has a “title” attribute with a non-empty value
Otherwise, without this change, the accessible name unexpectedly isn’t
computed correctly for those cases.
As shown in the test added by this patch, it was possible to re-assign
the `this` value of a member function call while it was executing.
Let's copy the original this value like we already do with the callee.
Fixes#2226.
This will no longer be true once we implement at-rules nested inside
style rules, for example:
```css
.foo {
color: yellow;
@media (min-width: 800px) {
color: orange;
}
}
```
If a rule gets its caches cleared because it's moved in the OM, then its
child rules' caches are likely invalid and need clearing too.
Assuming that caches only point "upwards", this will correctly clear
them all. For the time being that will be true.
This implements the `is_valid_in_the_current_context()` methods by
maintaining a stack of contexts, such as whether we're inside a style
rule, or an `@media` block, or the condition of a `@supports` rule.
This is implemented by using a GPU-accelerated surface for <canvas> when
a GPU context is available.
A side effect of this change is that all canvas modifications have to be
performed through Gfx::Painter, and whenever its content has to be
accessed, we need to take a snapshot of the corresponding GPU surface.
A new DrawPaintingSurface display list command is introduced to allow
cheap blitting of canvas content without having to read GPU surface
content into RAM.
Since the Vulkan context is currently only used by LibGfx, it could be
moved there to avoid having Vulkan as a dependency for everything that
uses LibCore.
Since the Metal context is currently only used by LibGfx, it could be
moved there to avoid having Metal as a dependency for everything that
uses LibCore.
This is required to share GPU context creation code between display list
player, which resides in LibWeb, and PainterSkia, which handles <canvas>
painting.
We want the "raw" value here. The spec sort of assumes we are sending JS
values over the wire, whereas we are actually sending AK::JsonValue. So
using the JSON clone AO here is our best bet.
Chromium has a larger list of boolean attributes, and WPT depends on it.
We must also compare attribute names case-insensitively.
Note this method is only used by WebDriver.
We can't invalidate after the removal has taken effect, since that means
invalidation won't be able to find potentially affected siblings and
ancestors by traversing from the invalidation target.
