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.
There's no mention in the spec of this being optional, all the places
that call it always pass a NavigationParams directly, and we're
VERIFYing that it's got a value too!
Before this change, we would only cache and reuse Gfx::ScaledFont
instances for downloaded CSS fonts.
By moving it into Gfx::VectorFont, we get caching for all vector fonts,
including local system TTFs etc.
This avoids a *lot* of style invalidations in LibWeb, since we now vend
the same Gfx::Font pointer for the same font when used repeatedly.
We don't need to skip whitespace at the top level because that's already
done before we're called. But we do still have to skip it inside the
`add()` function
This aligns Workers and Window and MessagePorts to all use the same
mechanism for transferring serialized messages across realms.
It also allows transferring more message ports into a worker.
Re-enable the Worker-echo test, as none of the MessagePort tests have
themselves been flaky, and those are now using the same underlying
implementation.
Ultimately, this API should probably be replaced with something that
updates a cache on relevant DOM mutations instead of regenerating
the list of property names again and again.
The resource:// scheme is used for Core::Resource files. Currently, any
users of resource:// URLs in Ladybird must manually create the Resource
and extract its data. This will allow for passing the resource:// URL
along for LibWeb to handle.
