This allows us to get rid of property_table_ordered() which was a
heavy-handed way of iterating properties in insertion order by first
copying them to a sorted Vector.
Clients can now simply iterate property_table() directly.
3% speed-up on Kraken/ai-astar.js :^)
Fixes regression introduced in b4fe118dff
The `WebContentConsoleClient` needs to be created not just once, but
for every new document. Although the JS Console window allows
communication only with the active document associated with the
top-level browsing context, we still need a console client for each
iframe's document to ensure their console logs are printed.
In the future, we might consider adding the ability to switch which
document the JS Console window communicates with.
Fixes https://github.com/SerenityOS/serenity/issues/21117
The VirtIO specification defines many types of devices with different
purposes, and it also defines 3 possible transport mediums where devices
could be connected to the host machine.
We only care about the PCIe transport, but this commit puts the actual
foundations for supporting the lean MMIO transport too in the future.
To ensure things are kept abstracted but still functional, the VirtIO
transport code is responsible for what is deemed as related to an actual
transport type - allocation of interrupt handlers and tinkering with low
level transport-related registers, etc.
If `load_document()` is called with a response that has a mime type we
can't use to build a document, we should return nullptr as the spec
says, instead of crashing. Also we should not crash if error happened
during parsing.
This fixes issue reproducing with following steps:
1. Node::insert_before() adopts a node into another document.
2. Node::insert_before() runs insertion steps for adopted node (adopted
node style is not invalidated yet).
3. Insertion steps execute spin_until() on event loop.
4. The next task on event loop does Document::update_style() which
requires layout tree rebuild.
5. Layout tree rebuild fails because there is a node with invalidated
style.
This is not in the spec, but we need to make sure that "apply the
history step" for initial navigation to about:blank in iframe is
applied before subsequent navigations. Otherwise, "set ongoing
navigation" call during "about:blank" traversal might abort subsequent
ongoing navigation which is not expected to happen.
During the destruction of a navigable, we need to use the pointer to
the navigable that was saved at the beginning of the function. This
is because `Node::navigable()` will return a nullptr in subsequent
steps after the navigable's document becomes inactive.
