We don't create a ChromeProcess in headless-browser, so it is currently
not increasing it's open file limit. This is causing crashes on macOS,
which has a very low default limit.
This uses the setup-python action in the setup action to install python
3.12, and removes the --break-system-packages hack that the system pip
requires.
Before this change viewport was allowed to be scrolled whenever it has a
scrollable overflow, which is not correct when overflow is specified to
be hidden.
Partially reverting a3149c1ce9
Spinning the event loop was causing a crash on:
https://wpt.live/url/percent-encoding.window.html
As it was turning what is meant to be a synchronous operation into an
asynchronous one.
The sequence demonstrated by the reproducing test is as follows:
* A src attribute is changed for the iframe
* process_the_iframe_attributes entered with valid content navigable
* Event loop is spun, allowing the queued iframe removal to execute
* process_the_iframe_attributes continues with null content navigable
* 💥
This reverts commit 556a0936dd.
This was causing a large slow down in WPT, and a crash on macOS during
session shutdown when running WebDriver manually.
Transitions are currently not implemented for pseudo elements which
causes the transition to be applied to the "real"/"parent" element. When
a transition adjusts width/height on a pseudo element this causes the
real elements layout to break.
As a quick fix we just skip doing transitions when they are against
pseudo elements.
We were overly aggressive in clipping SVG roots, which effectively made
them behave as if they always had `overflow: hidden`.
This fixes incorrect clipping of the logo on https://basecamp.com/
Which fixes the following WPT test from failing due to issues stemming
from all of the windows which have been opened.
https://wpt.live/url/failure.html
This will give us 1205 new subtests passing in WPT.
We currently create a single WebView and run all 1400+ LibWeb tests in
serial over that WebView. Instead, let's create as many WebViews as
there are processes on the system, and run LibWeb tests concurrently
over those views.
To do this performantly requires that we never block the main thread of
the headless-browser process once the tests are running. Doing so will
effectively pause execution of all other tests. So test execution is now
Promise-based.
On my machine (with a hardware concurrency of 32), this reduces the run
time of LibWeb tests from 31.382s to 3.640s. CPU utilization increases
from 5% to 67%.
Instead, just log the view's current URL when the WebView crashes. It
won't make any sense to track the executing test this way once there are
many tests running concurrently.
We currently run all tests in a single WebView instance. That instance
owns the process-wide RequestClient / ImageDecoderClient, so if we were
to create a second instance, we'd run into trouble.
This migrates ownership of these services to the Application class, and
makes the Application own the WebView. In the future, this will let the
Application own a list of views.
We currently pass around the individual fields of the Application class
to a bunch of free functions. This makes adding a new field, and passing
it all the way to e.g. run_dump_test pretty annoying, as we have to go
through about 5 function calls.
This will get much worse in an upcoming patch to run LibWeb tests
concurrently. There, we will have to further pass these flags around as
async lambda value captures.
To make this nicer, just access the flags from Application::the(), which
is how the "real" UIs access their application objects as well.
If, by the time we need to schedule rendering of the next frame, the
previous one is still not processed, we could skip it instead of growing
task queue.
Should help with https://github.com/LadybirdBrowser/ladybird/issues/1647
When the flex container is sized under a min-content constraint in the
main axis, any flex items with a percentage main size should collapse
to zero width, not take up their own intrinsic min-content size.
This is not in the spec, but matches how other browsers behave.
Fixes an issue where the cartoons on https://basecamp.com/ were way
too large. :^)
Static position of a box is defined by formatting context type it
belongs to, so let's define this algorithm separately for each FC
instead of assuming FormattingContext::calculate_static_position_rect()
understands how to handle all of them.
Also with this change calculate_static_position_rect() is no longer
virtual function.
At least on my mac, clock_gettime only provides millisecond resolution.
So if many WebContent processes are opened at once, it is not unlikely
that they will all create their backing stores within the same ms. When
that happens, all but the first will fail (and crash).
To prevent this, generate the shared memory file name based on the PID
and a static counter.
We are currently trying to access the current parent and top-level
browsing contexts from the current BC itself. However, if the current BC
is closed, its association to the parent and top-level BCs is lost, and
we are no longer able to handle WebDriver endpoints involving those BCs.
Instead, let's store the parent and top-level BCs separately, and update
them in accordance with the spec.
We were already allowing intrinsic height layout to see definite widths,
and I can't think of a reason *not* to allow it the other way around.
More importantly, this fixes an issue where things with an aspect ratio
didn't have a height to resolve against before.
Makes the logo show up on https://basecamp.com/ :^)
If we end up in a situation where the navigable no longer has an active
window, we can't perform navigation or many other navigable operations.
These are all ad-hoc, since the navigables spec is basically all written
as if there's always an active window. Unfortunately, the active window
comes from the active document's browsing context, which is a nullable
concept even in the spec, so we do need to deal with null here.
This removes all the locally reproducible crashes when running WPT over
the legacy Japanese encoding directory on my computer.
Yes, this is a bit of a monkey patch, but it should be harmless since
we're (as I understand it) dealing with navigables that are still
hanging around with related tasks queued on them. Once all these tasks
have been completed, the navigables will go away anyway.
Because of the previous awkward factoring of Origin we had two
implementations of Origin serializing and creation. Move the
implementation of DOMURL::url_origin into URL::origin, and
instead use the implemenation of URL::Origin::serialize for
serialization (replacing URL::serialize_origin).
This happens to fix 8 URL subtests as the two implemenations had
diverged, and URL::serialize_origin was previously missing the spec
changes of: whatwg/url@eee49fd and whatwg/url@fff33c3
This closer matches specification - and removes any dependency on
LibWeb in the implementation of DOMURL::url_origin.
It is also one step closer to moving BlobURLRegistry to a singleton
process to match LibWeb's multiprocess Worker architecture.
While Origin is defined in the HTML spec - this leaves us with quite an
awkward relationship as the URL spec makes use of AO's from what is
defined in the HTML spec.
To simplify this factoring, relocate Origin into LibURL.
