This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
The way we've been creating DOM::Document has been pretty far from what
the spec tells us to do, and this is a first big step towards getting us
closer to spec.
The new Document::create_and_initialize() is called by FrameLoader after
loading a "text/html" resource.
We create the JS Realm and the Window object when creating the Document
(previously, we'd do it on first access to Document::interpreter().)
The realm execution context is owned by the Environment Settings Object.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
After this change, LibWeb now expects Web::ImageDecoding::Decoder to be
pre-initialized with a concrete implementation before using the webpage.
The previous implementation, based on the ImageDecoder service, has been
provided directly through an adapter in LibWebClient, and is now used as
the default value by WebContent.
HTML, CSS, JS and text files (among other things) can all legitimately
be empty. Other types may be invalid, but that will be caught when
trying to parse it as a document, so this check can safely be removed.
Block the replacement of the favicon by the default favicon loader
when a favicon that is loaded through a link tag is already active.
This way, the favicon in the link tags will be prioritized against
the default favicons from `/favicon.ico` or the seranity default icon.
BrowsingContext shouldn't be scrolling itself, instead it has to update
the layout (to ensure that we have current document metrics, and then
ask the PageClient nicely to scroll it.
This fixes an issue where BrowsingContext sometimes believed itself to
be scrolled, but OOPWV had a different idea.
We now validate that the provided tag names are valid XML tag names,
and otherwise throw an "invalid character" DOM exception.
2% progression on ACID3. :^)
This necessitated making HTMLParser ref-counted, and having it register
itself with Document when created. That makes it possible for scripts to
add new input at the current parser insertion point.
There is now a reference cycle between Document and HTMLParser. This
cycle is explicitly broken by calling Document::detach_parser() at the
end of HTMLParser::run().
This is a huge progression on ACID3, from 31% to 49%! :^)
According to Fetch, we must send an Accept header with the value
"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
for document, iframe and frame requests.
https://fetch.spec.whatwg.org/#concept-fetch
Required by uber.com.
Since we were previously relying on Document::set_cookie in order to
set cookies received as a 'Set-Cookie' response header, we would ignore
any response header cookies in redirect (status code 3xx) responses.
While this behaviour is not strictly enforced in the specification,
most major browsers do set cookies in redirect responses, and some
sites (e.g. Cookie Clicker) rely on this behaviour.
Since cookies are stored per-site and not per-document, this behaviour
is achieved by simply decoupling the cookie set mechanism from it.
As per RFC7231 the Location header field has different meanings for
different response status codes:
For 201 (Created) responses, the Location value refers to the primary
resource created by the request.
For 3xx (Redirection) responses, the Location value refers to the
preferred target resource for automatically redirecting the request.
The "completely finish loading" algorithm (from the HTML spec) is
responsible for sending a "load" event to nested browsing context
containers (iframes).
This patch removes the old mechanism for sending "load" events, which we
had mistakenly kept around, causing two events to be sent instead of
one. :^)
An image document is the synthetic DOM::Document we create to wrap an
image when you open the URL of an image directly in a web view.
The path that creates these documents will now also call out to the
separate ImageDecoder process for the actual decoding work.
Some sites don't have favicon.ico, so we may get 404 response.
In such cases, ResourceLoader still calls success_callback.
For favicon loading, we are not checking response headers or payload
size.
This will ultimately fail in Gfx::ImageDecoder::try_create().
So avoid unnecessary work by returning early, if data is empty.
This namespace will be used for all interfaces defined in the URL
specification, like URL and URLSearchParams.
This has the unfortunate side-effect of requiring us to use the fully
qualified AK::URL name whenever we want to refer to the AK class, so
this commit also fixes all such references.
We already have a base class for frame elements that we call
BrowsingContextContainer. This patch makes BrowsingContext::container()
actually return one of those.
This makes us match the spec names, and also solves a FIXME about having
a shared base for <frame> and <iframe>. (We already had the shared base,
but the pointer we had there wasn't tightly typed enough.)
This fixes a long-standing bug where the view wouldn't update when
navigating to a new page after looking at the ACID2 test. This happened
because ACID2 actually scrolls the viewport far down. We didn't reset
the scroll position upon navigation, and so the new page thought that
we were still scrolled very far down, and this broke the invalidation
rect calculations.
Previously in Browser, when we navigate back from a page that has an
icon to a page that does not have an icon, the icon does not update and
the old icon is displayed because FrameLoader does not set the default
favicon when the favicon cannot be loaded. This patch ensures that
Browser receives a new icon bitmap every time a load takes place.
To transparently support multi-frame images, all decoder plugins have
already been updated to return their only bitmap for frame(0).
This patch completes the remaining cleanup work by removing the
ImageDecoder::bitmap() API and having all clients call frame() instead.
Previously, ImageDecoder::create() would return a NonnullRefPtr and
could not "fail", although the returned decoder may be "invalid" which
you then had to check anyway.
The new interface looks like this:
static RefPtr<Gfx::ImageDecoder> try_create(ReadonlyBytes);
This simplifies ImageDecoder since it no longer has to worry about its
validity. Client code gets slightly clearer as well.
The LexicalPath instance methods dirname(), basename(), title() and
extension() will be changed to return StringView const& in a further
commit. Due to this, users creating temporary LexicalPath objects just
to call one of those getters will recieve a StringView const& pointing
to a possible freed buffer.
To avoid this, static methods for those APIs have been added, which will
return a String by value to avoid those problems. All cases where
temporary LexicalPath objects have been used as described above haven
been changed to use the static APIs.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
Surprisingly this is not used by the browser's page reload functionality
but only JS's location.reload() - that's probably why this hasn't been
noticed yet. Make sure we notify the page client about the load start in
that case as well. :^)
Otherwise we would sometimes (dependent on the load time, I believe) end
up setting the document and eventually calling title change callbacks
before communicating that the page started loading.
This patch implements the HTML specification's "encoding sniffing
algorithm", which is used when no encoding can be obtained from the
Content-Type header (either because it doesn't contain a charset=...)
value or the file has not been opened via HTTP (as with local files).
It also modifies the creator of the HTMLDocumentParser to use the new
HTMLDocumentParser::create_with_uncertain_encoding static method, which
runs the encoding sniffing algorithm before instantiating the parser.
This now allows us to load local HTML pages (or remote pages without a
charset specified in the 'Content-Type' header) with a non-UTF-8
encoding such as 'windows-1252'. This would previously crash the
browser. :^)
