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.
When loading a canned version of reddit.com, we end up parsing many many
shadow tree style sheets of roughly ~170 KiB text each.
None of them have '\r' or '\f', yet we spend 2-3 ms for each sheet just
looping over and reconstructing the text to see if we need to normalize
any newlines.
This patch makes the common case faster in two ways:
- We use TextCodec::Decoder::to_utf8() instead of process()
This way, we do a one-shot fast validation and conversion to UTF-8,
instead of using the generic code-point-at-a-time callback API.
- We scan for '\r' and '\f' before filtering, and if neither is present,
we simply use the unfiltered string.
With these changes, we now spend 0 ms in the filtering function for the
vast majority of style sheets I've seen so far.
This way, we still perform UTF-8 validation, but don't go through the
slow generic code path that rebuilds the decoded string one code point
at a time.
This was a bottleneck when loading a canned copy of reddit.com, which
ended up being ~120 MiB large.
- Time spent decoding UTF-8 before this change: 1192 ms
- Time spent decoding UTF-8 after this change: 154 ms
That's still a long time, but 7.7x faster is nothing to sneeze at! :^)
Note that if the input fails UTF-8 validation, we still fall back to
the slow path and insert replacement characters per the WHATWG Encoding
spec: https://encoding.spec.whatwg.org/#utf-8-decode
This change makes OpenType::Name::string_for_id handle fonts whose names
are UTF-16-encoded (along with handling UTF-8-encoded names).
Otherwise, without this change, the existing code assumes the names are
UTF-8-encoded, fails gracelessly if they’re not, and crashes.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/75
This is the expected behavior per the HTML spec. Fixes an issue where
styling these elements wouldn't have the expected effect unless you also
set the display property.
This change makes the notes-push.yml·workflow fetch the entire history
on each push, rather than just the one HEAD commit it otherwise sees.
Because we push multiple commits from PR merges, git-gloss need access
on each push to an arbitrary number of commits (however many commits
were pushed in a PR that got merged). There’s no easy way from GH
Actions to know how may commits got pushed at the same time. So we
instead fetch the whole history.
For performance, rather than slowly incrementing the capacity of the
rope string's buffer, compute an approximate length for that buffer to
be reserved up front.
Currently, invoking StringBuilder::to_string will re-allocate the string
data to construct the String. This is wasteful both in terms of memory
and speed.
The goal here is to simply hand the string buffer over to String, and
let String take ownership of that buffer. To do this, StringBuilder must
have the same memory layout as Detail::StringData. This layout is just
the members of the StringData class followed by the string itself.
So when a StringBuilder is created, we reserve sizeof(StringData) bytes
at the front of the buffer. StringData can then construct itself into
the buffer with placement new.
Things to note:
* StringData must now be aware of the actual capacity of its buffer, as
that can be larger than the string size.
* We must take care not to pass ownership of inlined string buffers, as
these live on the stack.
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.
This change, for each commit pushed/merged to master:
- causes new git Notes with GitHub PR/issue/reviewer/author links to be
auto-generated for that commit
- pushes the updated refs/notes/commits tree+references back to the repo
This change will make it easier to disable screenshot comparison tests
on a specific platform or have per-platform expectations.
Additionally, it's nice to be able to tell if a ref-test uses a
screenshot as an expectation by looking at the test path.
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
GCC 14 emits a warning when an always succeeding `dynamic_cast`'s return
value is compared to NULL inside the `AK::is<T>(U)` template when `T` ==
`U`.
While warning on tautological `is` calls seems useful, it's a bit
awkward when it comes from a function template where the cast may fail
in some instantiation. There is a GCC bug open for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115664
Work around the warning by performing the algorithm on the base type
(`EventTarget`), with a wrapper that casts it to the more specialized
input type.
Utf16View currently assumes host endianness. Add support for specifying
either big or little endianness (which we mostly just pipe through to
simdutf). This will allow using simdutf facilities with LibTextCodec.
