Implements https://github.com/whatwg/html/pull/10007 which basically
moves style, layout and painting from HTML processing task into HTML
task with "rendering" source.
The biggest difference is that now we no longer schedule HTML event loop
processing whenever we might need a repaint, but instead queue a global
rendering task 60 times per second that will check if any documents
need a style/layout/paint update.
That is a great simplification of our repaint scheduling model. Before
we had:
- Optional timer that schedules animation updates 60 hz
- Optional timer that schedules rAF updates
- PaintWhenReady state to schedule a paint if navigable doesn't have a
rendering opportunity on the last event loop iteration
Now all that is gone and replaced with a single timer that drives
repainting at 60 hz and we don't have to worry about excessive repaints.
In the future, hard-coded 60 hz refresh interval could be replaced with
CADisplayLink on macOS and similar API on linux to drive repainting in
synchronization with display's refresh rate.
Fixes crashing on https://playbiolab.com/ in
VERIFY(page.client().is_ready_to_paint()) caused by attempting to start
the next repaint before the ongoing repaint is done.
This is an ad-hoc implementation that resolves the ready() promise once
the document and all fonts collected by the style computer are done
loading. A spec-compliant implementation would include creating a proxy
CSS::FontFace for each @font-face and correctly implementing the
specification steps for font fetching, but we are far from there yet.
This hackish implementation should yield good WPT progress because it
will actually start waiting for the Ahem font to load before capturing
layout measurements. For example, it makes
https://wpt.live/css/css-grid/abspos/positioned-grid-descendants-001.html
go from 0/100 to 36/100 passing subtests.
This also fixes a bug where task IDs were being deallocated from the
wrong IDAllocator. I don't know if it was actually possible to cause any
real trouble with that mistake, nor do I know how to write a test for
it, but this makes the bug go away.
Unit tests on macOS deadlock because the WebContent process is waiting
for the next opportunity to render before a screenshot is taken. For
some reason unknown to myself, this opportunity never arrives. In
order to not deadlock, screenshot requests are now also processed
separately from rendering.
This is an attempt to fix the hanging CI on macOS caused by some
screenshot requests being stuck unprocessed. With this change, we at
least make sure that the HTML event loop processing, which triggers
repainting, will happen as long as there are navigables that need to be
repainted.
...instead of scheduling repaint timer in PageClient.
This change fixes flickering on Discord that happened because:
- Event loop schedules repainting by activating repaint timer
- `Document::tear_down_layout_tree()` destroys paintable tree
- Repaint timer invokes callback and renders an empty frame because
paintable tree was destroyed
Changes the signature of queue_global_task() from AK:Function to
JS::HeapFunction to be more clear to the user of the function that this
is what it uses internally.
This changes the signature of queue_a_microtask() from AK:Function to
JS::HeapFunction to be more clear to the user of the functions that this
is what is used internally.
This reverts commit 664611bae4.
It seems like the HTML spec has been misinterpreted and this text:
"... Note that in this setup, the processing model still enforces that
the user agent would never process events from any one task source out
of order."
does not mean we can't interrupt execution of task by a task with the
same task source. It just says they should be processed in the order
they were added.
Fixes hanging while navigating from PR list to PR page on GitHub.
From HTML spec https://html.spec.whatwg.org/#definitions-3
"... Note that in this setup, the processing model still enforces that
the user agent would never process events from any one task source out
of order."
I can't come up with an example that is fixed by this change. However,
debugging a bug caused by violating this assumption from the spec is
likely to be very painful.
...and use HeapFunction instead of SafeFunction for task steps.
Since there is only one EventLoop per process, it lives as a global
handle in the VM custom data.
This makes it much easier to reason about lifetimes of tasks, task
steps, and random stuff captured by them.
Implements the "top layer" concept from "CSS Positioned Layout Module
Level 4" specification.
- The tree builder is modified to ensure that layout nodes created by
top layer elements are children of the viewport.
- Implements missing steps in `showModal()` to add an element top top
layer.
- Implements missing steps in `close()` to remove an element from top
layer.
Further steps could be:
- Add support for `::backdrop` pseudo-element.
- Implement the "inert" concept from HTML spec to block hit-testing
when element from top layer is displayed.
Fixes delayed repainting in the following case:
1. Style or layout invalidation triggers html event loop processing.
2. Event loop processing does nothing because there is no rendering
opportunity.
3. Style or layout change won't be reflected until something else
triggers event loop processing
In our implementation of the "apply the history step" algorithm, we
have to spin-wait for the completion of tasks queued on the event loop.
Before this change, we allowed tasks from any source to be executed
while we were waiting. It should not be possible because it allows to
interrupt history step application by anything, including another
history step application.
Fixes https://github.com/SerenityOS/serenity/issues/23598
Document::navigable() can be unpleasantly slow, since we don't have a
direct link between documents and navigables at the moment. So let's not
call it twice when once is enough.
Resolves a performance regression from
8ba18dfd40, where moving paint scheduling
to `EventLoop::process()` led to unnecessary repaints.
This update introduces a flag to trigger repaints only when necessary,
addressing the issue where repaints previously occurred with each event
loop process, irrespective of actual changes.
With this commit, we are finally running animations off of the web
animations spec! A lot of the work StyleComputer is doing is now done
elsewhere. For example, fill-forward animations are handled by
Animation::is_relevant() returning true in the after phase, meaning the
"active_state_if_fill_forward" map is no longer needed.
Extends event loop processing steps to include gathering and
broadcasting resize observations.
Moves layout updates from Navigable::paint() to event loop processing
steps. This ensures resize observation processing occurs between layout
updates and painting.
In this change, updating layout and painting are moved to the EventLoop
processing steps. This modification allows the addition of resize
observation dispatching that needs to happen in event loop processing
steps and must occur in the following order relative to layout and
painting:
1. Update layout.
2. Gather and broadcast resize observations.
3. Paint.
This prevents goal conditions that rely on tasks that are currently in
flight on the task queue (or were just submitted) from blocking the
event loop until an IPC event fires to kick the native event loop.
The FIXME here describes an old constraint on JS Interpreters which no
longer holds. It hails from a time when we had the global object and
JS realm attached to the document.
The main missing features are rootMargin, proper nested browsing
context support and content clip/clip-path support.
This makes images appear on some sites, such as YouTube and
howstuffworks.com.
At the end of HTML::EventLoop::process(), the loop reschedules itself if
there are more runnable tasks available.
However, the condition was flawed: we would reschedule if there were any
microtasks queued, but those tasks will not be processed if we're
currently within the scope of a microtask checkpoint.
To fix this, we now only reschedule the HTML event loop for microtask
processing *if* we're not already in a microtask checkpoint.
This fixes the 100% CPU churn seen when looking at PRs on GitHub. :^)
Instead of using Core::EventLoop and Core::Timer directly, LibWeb now
goes through a Web::Platform abstraction layer instead.
This will allow us to plug in Qt's event loop (and QTimer) over in
Ladybird, to avoid having to deal with multiple event loops.
