To achieve this goal:
- The Browser unveils "/tmp/portal/filesystemaccess"
- Pass the page through LoadRequest => ResourceLoader
- ResourceLoader requests a file to the FileSystemAccessServer via IPC
- OutOfProcessWebView handles it and sends a file descriptor back to
the Page.
This is the final component that required LibProtocol as a dependency
of LibWeb. With this, we can now remove the dependency, and LibWeb no
longer requires IPC to work :^)
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.
When a Resource is converted to an ImageResource, evict the original
resource from cache. The original resource's data has been moved, so on
a warm reload of a page, when that resource is loaded from cache, it
would not have any data to actually show.
HTMLObjectElement, when implemented according to the spec, does not know
the resource type specified by the 'data' attribute until after it has
actually loaded (i.e. it may be an image, XML document, etc.). Currently
we always use ImageLoader within HTMLObjectElement to load the object,
but will need to use ResourceLoader instead to generically load data.
However, ImageLoader / ImageResource have image-specific functionality
that HTMLObjectElement still needs if the resource turns out to be an
image. This patch will allow (only) HTMLObjectElement to convert the
generic Resource to an ImageResource as needed.
- Switch from "Mozilla/4.0" to "Mozilla/5.0" to match other browsers.
- Remove references to KHTML and Gecko.
- Identify ourselves as "LibWeb+LibJS/1.0 Browser/1.0"
New UA: "Mozilla/5.0 (SerenityOS; x86_64) LibWeb+LibJS/1.0 Browser/1.0"
Previously, we'd invoke the load/fail callbacks synchronously for
resources that were already loaded and cached.
This patch uses deferred_invoke() in the already-loaded case to ensure
that we always invoke these callbacks in a consistent manner.
This isn't to fix a specific issue, but rather because I kept seeing
these callbacks being invoked synchronously on top of an already-tall
call stack, and it was hard to reason about what was going on.
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.
This basically copies some logic from FrameLoader to ImageLoader.
Ideally we'd share this code, but for now let's just get redirected
images to show up. :^)
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.
In order to avoid having multiple instances, we were keeping a pointer
to these singleton objects and only allocating them when it was null.
We have `__cxa_guard_{acquire,release}` in the userland, so there's no
need to do this dance, as the compiler will ensure that the constructors
are only called once.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
This change unfortunately cannot be atomically made without a single
commit changing everything.
Most of the important changes are in LibIPC/Connection.cpp,
LibIPC/ServerConnection.cpp and LibCore/LocalServer.cpp.
The notable changes are:
- IPCCompiler now generates the decode and decode_message functions such
that they take a Core::Stream::LocalSocket instead of the socket fd.
- IPC::Decoder now uses the receive_fd method of LocalSocket instead of
doing system calls directly on the fd.
- IPC::ConnectionBase and related classes now use the Stream API
functions.
- IPC::ServerConnection no longer constructs the socket itself; instead,
a convenience macro, IPC_CLIENT_CONNECTION, is used in place of
C_OBJECT and will generate a static try_create factory function for
the ServerConnection subclass. The subclass is now responsible for
passing the socket constructed in this function to its
ServerConnection base; the socket is passed as the first argument to
the constructor (as a NonnullOwnPtr<Core::Stream::LocalServer>) before
any other arguments.
- The functionality regarding taking over sockets from SystemServer has
been moved to LibIPC/SystemServerTakeover.cpp. The Core::LocalSocket
implementation of this functionality hasn't been deleted due to my
intention of removing this class in the near future and to reduce
noise on this (already quite noisy) PR.
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.
All CSS loading is now done by the relevant classes:
- CSSImportRule, which loads its linked stylesheet
- HTMLStyleElement, which "loads" its contents
- HTMLLinkElement, which loads its linked stylesheet
