This is quite niche, but lets us convert parsing methods to accepting
TokenStream, while still being able to call them when we just have a
lone token. Specifically we'll use this in the next commit, but it's
likely to also be useful as a stop-gap measure when converting more
parsing methods.
Frequently we want to parse "anything that's a `<length-percentage>`" or
similar, which could be a constant value or a calculation, but didn't
have a nice way of doing so. That meant repeating the same "try and
parse a dimension, see if it's the right type, then maybe try and parse
a calculation and see if that's the right type" boilerplate code. Or
more often, forgetting about calculations entirely.
These helpers should make that a lot more convenient to do. And they
also use TokenStream, so we can eventually drop the old `parse_length()`
method.
All DOM node mutation IPCs now invoke an async completion IPC after the
DOM is mutated. This allows consolidating where the Inspector updates
its view and the selected DOM node.
This also allows improving the response to removing a DOM node. We would
previously just select the <body> tag after removing a DOM node because
the Inspector client had no idea what node preceded the removed node.
Now the WebContent process can just indicate what that node is. So now
after removing a DOM node, we inspect either its previous sibling (if it
had one) or its parent.
Rename them from "did_get_*" to "did_inspect_*", to correspond to the
request methods "inspect_dom_tree" and "inspect_accessibility_tree". No
functional change, but this makes it a bit easier to stare at IPC files
side-by-side and know which response method corresponds to a request
method at a quick glance.
With this change, we create substantially fewer border painting
commands, which means fewer reallocations of the vector that stores
commands.
This makes the rendering of
https://html.spec.whatwg.org/multipage/browsing-the-web.html visibly
faster, where we allocated ~10 of such commands now vs ~8000 before.
This commit adds minimal support for compiler-instrumentation based
memory access sanitization.
Currently we only support detection of kmalloc redzone accesses, and
kmalloc use-after-free accesses.
Support for inline checks (for improved performance), and for stack
use-after-return and use-after-return detection is left for future PRs.
We already have the src attribute stored as a String, so it's completely
wasteful to convert it to a ByteString. We were even doing it twice when
loading each image.
Much of the UTF-8 data that we'll iterate over will be ASCII only,
and we can get a significant speed-up by simply having a fast path
when the iterator points at a byte that is obviously an ASCII character
(<= 0x7F).
Since we're already building up a percent-encoded ASCII-only string
in the internal parser buffer, there's no need to do a second UTF-8
validation pass before assigning each part of the parsed URL.
This makes URL parsing signficantly faster.
Instead of do a wrappy MUST(try_append_code_point()), we now inline
the UTF-8 encoding logic. This allows us to grow the buffer by the
right increment up front, and also removes a bunch of ErrorOr ceremony
that we don't care about.
Once we know that a code point must be a valid ASCII character,
we now cast it to `char` and avoid the expensive generic
StringView::contains(u32 code_point) checks.
This dramatically speeds up URL parsing.
When resolving a rope, we've already taken care to resolve it to
a UTF-8 byte stream. There's no need to do a separate pass just for
validating the data again.
This was noticeable in some profiles. I made a simple microbenchmark
that gets a 30% speed-up:
("x" + "y".repeat(100_000_000)).trimStart()
UTF8Decoder was already converting invalid data into replacement
characters while converting, so we know for sure we have valid UTF-8
by the time conversion is finished.
This patch adds a new StringBuilder::to_string_without_validation()
and uses it to make UTF8Decoder avoid half the work it was doing.
Instead of using a StringBuilder, add a String::repeated(String, N)
overload that takes advantage of knowing it's already all UTF-8.
This makes the following microbenchmark go 4x faster:
"foo".repeat(100_000_000)
And for single character strings, we can even go 10x faster:
"x".repeat(100_000_000)
The fix here was to stop using StringBuilder::append(char) when told to
append a code point, and switch to StringBuilder::append_code_point(u32)
There's probably a bunch more issues like this, and we should stop using
append(char) in general since it allows building of garbage strings.
I noticed while debugging a fully downloaded page that it was trying
to preconnect to a file:// host. That doesn't make any sense, so let's
add a tiny bit of logic to ignore preconnect requests for file: and
data: URLs.
With this change, instead of applying scroll offsets during the
recording of the painting command list, we do the following:
1. Collect all boxes with scrollable overflow into a PaintContext,
each with an id and the total amount of scrolling offset accumulated
from ancestor scrollable boxes.
2. During the recording phase assign a corresponding scroll_frame_id to
each command that paints content within a scrollable box.
3. Before executing the recorded commands, translate each command that
has a scroll_frame_id by the accumulated scroll offset.
This approach has following advantages:
- Implementing nested scrollables becomes much simpler, as the
recording phase only requires the correct assignment of the nearest
scrollable's scroll_frame_id, while the accumulated offset from
ancestors is applied subsequently.
- The recording of painting commands is not tied to a specific offset
within scrollable boxes, which means in the future, it will be
possible to update the scrolling offset and repaint without the need
to re-record painting commands.
The decoder assumes that k's sampling factor matches y's at the moment.
Better to error out than to silently render something broken.
For ycck, covered by ycck-2111.jpg in the tests.
This scan code set is more advanced than the basic scan code set 1, and
is required to be supported for some bare metal hardware that might not
properly enable the PS2 first port translation in the i8042 controller.
LibWeb can now also generate bindings for keyboard events like the Pause
key, as well as other function keys (such as Right Alt, etc).
The logic for handling scan code sets is implemented by the PS2 keyboard
driver and is abstracted from the main HID KeyboardDevice code which
only handles "standard" KeyEvent(s).
Instead of using a scan code, which for scan code set 2 will not
represent the expected character mapping index, we could just use
another variable in the KeyEvent structure that correctly points to the
character index.
This change is mostly relevant to the KeyboardMapper application, and
also to the WindowServer code, as both handle KeyEvents and need to
use the character mapping index in various situations.
This will be used later on by WindowServer so it will not use the
scancode, which will represent the actual character index in the
keyboard mapping when using scan code set 2.
