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.
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.
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.
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.
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).
The BatchingDispatcher mechanism is used by HTMLImageElement to avoid
decoding one image at a time, since interleaving decode/layout/repaint
over and over takes way more time than doing many decodes followed by
a single layout/repaint pair.
Before this change, we didn't have a limit on how many batched loads
we'd allow ourselves to queue up, which could lead to situations where
more and more images kept being added to the queue, and never getting
processed.
This fixes the issue by putting an arbitrary limit (16) on the number
of batched image loads, and then allowing the flush to happen after
that instead of re-deferring processing.
If an image element has no alt attribute, other browsers don't fall back
to using the src attribute like we did.
This gave us a janky look while loading pages that other browsers don't
have, and it's not like seeing a partial URL is really helpful to the
user anyway.
Instead, we now pass String if we have one. In particular, this fixes an
issue where image elements with a data: URL src would copy the entire
URL string every time we painted (before the image had been decoded).
This was very noticeable on "fully downloaded" web pages where every
single image has been turned into a data: URL.
This code didn't account for position:fixed elements, which meant that
we'd swallow repaints for such elements when the viewport wasn't
scrolled to the top of the page.
We replace the incomplete optimization with a FIXME noting that this
needs to be handled correctly when reintroduced.
This stopped being called for anything without a navigable container
after 76a97d8, due to the early return. This broke SVG <use> elements
that reference elements defined later in the document.
This also removes the code for displaying `gemini://` documents. We
currently don't load documents from that protocol anyway - we hit
`attempt_to_create_a_non_fetch_scheme_document()` in `Navigable.cpp`
which is just a stub. It looks like we should be handling those
separately from regular "fetch" documents, so that's a task for a
future person.
(Apologies for bad commit title, it's hard to explain in such a short
space!)
We're going to need to call this for producing markdown and gemini
documents, both of which need a Document and Realm to fetch the entire
response body, so that they can then generate their HTML. So this
commit modifies `create_document_for_inline_content()` to take a lambda
instead of a fixed HTML string, to support these uses.
Also, we always return a nonnull pointer, so make that the return type.
This is a move and change in the same commit, (Sorry!) but all the
changes are to the function signature and step 6.
There's an unfortunate hack here. We have to load the media file's data
before we call `HTML::HTMLParser::the_end()` with our generated
document, otherwise the media element (`<img>`/`<audio>`/`<video>`)
never loads and that blocks the document's load event. The previous code
path also did this, which is perhaps why the bug was never noticed.
This is a little awkward: The spec requires when loading media documents
or ones that don't have a DOM, that we "act as if the user agent had
stopped parsing document" which means following this algorithm. Only a
few steps require an HTMLParser, but those that do, involve reaching
into its internals. The simplest solution I could think of (other than
duplicating this fairly hefty function) is making it static and taking
a Document and optional HTMLParser as parameters.
So far, we always call make_active() before update_readiness
(Complete), but this will soon not be the case once we implement the
spec document-loading algorithms.
Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
This function is currently very ad-hoc. This commit adds comments which
are almost entirely FIXMEs, so that we can then start filling in the
details one step at a time.
