Partly corresponds to this which adds numbering to some substeps:
d426109ea1
This is not a complete review of all the spec steps to check that
they're up to date - I just updated the parts affected by that above
commit, and then added some `->` marks to places I noticed it was
missing. There may be actual spec differences still.
An actual change that needs tackling later is that `handle_in_head()`'s
branch for `<template>` has some new steps related to custom element
registries.
This implements enough of the Geolocation spec that it is now possible
for websites to retrieve the current geo position or try to watch for
updates (which currently never happen).
As it stands now, it only returns a single emulated position that points
to San Francisco.
Documents created by DOMParser and fragment documents do not
have an origin set on the document by the spec. These documents
also happen to never become fully active.
By properly implementing the steps for the <img> element to only
update the image data for documents which are fully active, this
fixes a crash for img elements in these types of documents.
Unfortunately, this is not a full fix for the microtask queue case.
This is because it seems possible for node document for an <img>
element to be changed during the microtask queue for that document.
It is not clear to me how this can be fixed in a nice way.
This commit implements the fallback to the documents fallback base url
if the href of the first base element is a data or javascript url.
Additionally the frozen base url is set, if a base element becomes the
first base element with an href content attribute because the previous
one got removed.
When expanding "required line breaks", we now write directly into the
final StringBuilder instead of doing a pass of Vector remove/insert
operations first.
This removes a hot profile item on https://serpapi.com/
This list we are iterating over is removed from when there are
no more GC references to an ESO. This may be triggered by a GC
allocation. Since
UniversalGlobalScopeMixin::notify_about_rejected_promises performs
GC allocations (by, for example, allocating a GC function), it
is not safe to simply iterate over this list.
Fix this by taking a strong reference to all registered ESOs by
copying them across to a RootVector before iteration.
Fixes: #4652
Instead, porting over all users to use the newly created
Origin::create_opaque factory function. This also requires porting
over some users of Origin to avoid default construction.
As part of the effort of removing the default constructor of
Origin, since document has the origin set after construction,
port Document's origin over to an Optional<Origin>.
This exposes that we were never setting the origin of the document
during fragment parsing. For now, to maintain previous behaviour,
let's explicitly set it to an opaque origin.
All other viewport-related dimensions are referenced to by 'viewport',
so let's rename the member that stores the viewport size to prevent
further confusion.
Corresponds to d3effb701c
What a "fixed position container" is isn't clear to me, and we don't
seem to use that elsewhere, so I've left the steps using that as FIXMEs
for now.
There's no test coverage for this in WPT yet and I'm not confident
enough in the specific behaviour to write one myself. So, waiting on
https://github.com/web-platform-tests/wpt/issues/53214
`Element::ordinal_value` is called for every `li` element in
a list (ul, ol, menu).
Before:
`ordinal_value` iterates through all of the children of the list
owner. It is called once for each element: complexity $O(n^2)$.
After:
- Save the result of the first calculation in `m_ordinal_value`
then return it in subsequent calls.
- Tree modifications are intercepted and trigger invalidation
of the first node's `m_ordinal_value`:
- insert_before
- append
- remove
Results in noticeable performance improvement rendering' large
lists: from 20s to 4s for 20K elements.
Before:
`is<HTMLOLListElement>` and other similar calls in this commit
are resolved to `dynamic_cast`, which incurs runtime overhead
for resolving the type. The Performance hit becomes apparent
when rendering large lists. Callgrind analysis points to a
significant performance hit from calls to `is<...>` in
`Element::list_owner`.
Reference: Michael Gibbs and Bjarne Stroustrup (2006) Fast dynamic
casting. Softw. Pract. Exper. 2006; 36:139–156
After:
Implement inline `fast_is` virtual method that immediately
resolves the type. Results in noticeable performance improvement
2x-ish for lists with 20K entries.
Bonus: Convert starting value for LI elements to signed integer
The spec requires the start attribute and starting value to be
"integer". Firefox and Chrome support a negative start attribute.
FIXME: At the time of this PR, about 134 other objects resolve
`is<...>` to `dynamic_cast`. It may be a good idea to coordinate
similar changes to at least [some of] the ones that my have impact
on performance (maybe open a new issue?).
Fixes at least three WPT test that were previously timing out:
- html/semantics/embedded-content/media-elements/error-codes/error.html
- html/semantics/embedded-content/media-elements/location-of-the-media-resource/currentSrc.html
- html/semantics/embedded-content/the-video-element/video_crash_empty_src.html
The text track processing model would previously spin forever waiting
for the track URL to change. It would then recursively invoke itself
to handle the new URL, again entering the spin loop. This meant that
tracks could easily cause event loop hangs.
We now have an observer system to be notified when the track state
changes instead. This lets us exit the processing model and move on.
This change follows the pattern of our cookies persistence
implementation: the "browser" process is responsible for interacting
with the sqlite database, and WebContent communicates all storage
operations via IPC.
The new database table uses (storage_endpoint, storage_key, bottle_key)
as the primary key. This design follows concepts from the
https://storage.spec.whatwg.org/ and is intended to support reuse of the
persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For
now, `storage_endpoint` is always "localStorage", `storage_key` is the
website's origin, and `bottle_key` is the name of the localStorage key.
In upcoming changes StorageBottle will own pointers to GC-allocated
objects, so it needs to be a GC-allocated object itself to avoid
introducing more GC roots.
Instead, collect a list of all the elements with content-visibility:auto
after layout.
This way we can skip the tree traversal when updating the rendering.
This was previously eating up ~300 µs of the 60fps frame budget on
our GitHub repo pages (and even more on large pages).
This change implements following behavior defined in the spec:
https://html.spec.whatwg.org/multipage/web-messaging.html#examples-5
> The start() method, whether called explicitly or implicitly (by
setting onmessage), starts the flow of messages: messages posted on
message ports are initially paused, so that they don't get dropped on
the floor before the script has had a chance to set up its handlers.
Now we don't read bytes from the underlying transport socket until the
message port transitions to the enabled state. This required the
following places to explicitly enable the message port, because now,
when it actually matters, we must do so, or otherwise sent messages will
get stuck:
- `onmessage` attribute setter in DedicatedWorkerGlobalScope, because
it implicitly sets the onmessage handler for the worker's underlying
port.
- Stream API operations where the message port enabling steps were
previously marked as FIXMEs.
For example, button inputs shouldn't have a cursor
displayed in their text since they're not editable,
and are not meant to be editable.
Fixes#4140
Co-authored-by: Sam Atkins <sam@ladybird.org>
Not cleaning these up by rejecting or resolving the promise causes
the main thread to try to reject them at EventLoop::exit() time.
If the RenderThread has already been destroyed by then, we get into
use-after-free territory and segfault.
