We now follow the rules from the spec more closely, along with an
unspecified quirk for when the offsetParent is a non-positioned body
element. (Spec bug linked in a comment.)
This fixes a whole bunch of css-flexbox tests on WPT, which already had
correct layout, but the reported metrics from JS API were wrong.
We were mistakenly executing the current node's script instead of the
document's pending parsing-blocking script.
This caused ~1000 WPT tests to time out, since we never ended up firing
a load event for XHTML pages that load multiple external scripts.
This change is a preparation for the upcoming changes where display
list will be nested and the same display could be owned by multiple
display list items.
With this change display list player will be able to recurse into
executing another display list, without having to construct new display
list player. It is going to be useful in the upcoming changes to paint
a mask from a display list owned by a command.
Checking that the string parsed for the `font` property is not enough,
the spec also wants to rule out CSS-wide keywords like `inherit`. The
simplest way to do so is to check if it's a ShorthandStyleValue, which
also rules out use of `var()`; this matches other browsers' behaviour.
The newly-added test would previously crash, and now doesn't. :^)
Before this change, removing a style element from inside a shadow tree
would cause it to be unregistered with the document-level list of sheets
instead of the shadow-root-level list.
This would eventually lead to a verification failure if someone tried to
update the text contents of that style element, since it was still in
the shadow-root-level list, but now with a null owner element.
Fixes a crash on https://www.swedbank.se/
These were being immediately stored in JS::GCPtrs (and dutifully visited
by HTMLParser), so creating temporary handles for them was a complete
waste of time.
Instead of allowing arbitrarily large values (which could eventually
overflow an i32), let's just cap them at the same limit as Firefox does.
Found by Domato.
The EntryType has three possible values: Fetching, Failed or
ModuleScript. It is possible that we transition from Fetching to Failed
as in #13.1. Change the assertion to include the failed scenario.
Fixes: https://github.com/LadybirdBrowser/ladybird/issues/661
Enforce the use of the CPU backend in test mode to ensure that ref-tests
produce consistent results across different computers, as this
consistency cannot be achieved with the GPU backend.
We currently have 2 base64 coders: one in AK, another in LibWeb for a
"forgiving" implementation. ECMA-262 has an upcoming proposal which will
require a third implementation.
Instead, let's use the base64 implementation that is used by Node.js and
recommended by the upcoming proposal. It handles forgiving decoding as
well.
Our users of AK's implementation should be fine with the forgiving
implementation. The AK impl originally had naive forgiving behavior, but
that was removed solely for performance reasons.
Using http://mattmahoney.net/dc/enwik8.zip (100MB unzipped) as a test,
performance of our old home-grown implementations vs. the simdutf
implementation (on Linux x64):
Encode Decode
AK base64 0.226s 0.169s
LibWeb base64 N/A 1.244s
simdutf 0.161s 0.047s
Previously the input element was displayed with value 0, when no value
was set in the HTML. Now it uses `value_sanitization_algorithm()`, which
will calculate the default value.
In `value_sanitization_algorithm()` there was a logical mistake/typo.
The comment from the spec says "unless the maximum is less than the
minimum".
The added layout test would fail without the code changes.
Fixes#520
