With the addition of the 'fetch params' struct, the single ownership
model we had so far falls apart completely.
Additionally, this works nicely for FilteredResponse's internal response
instead of risking a dangling reference.
Replacing the public constructor with a create() function also found a
few instances of a Request being stack-allocated!
The HTMLIFrameElement does not create the nested browsing context on
insertion if the document does not have browsing context, which is not
set unless it's the active document.
Previously, in FrameLoader the document was not set as active until
after parsing, which led to iframes without nested browsing contexts,
and crashes.
Fixes#14207
URL had properly named replacements for protocol(), set_protocol() and
create_with_file_protocol() already. This patch removes these function
and updates all call sites to use the functions named according to the
specification.
See https://url.spec.whatwg.org/#concept-url-scheme
This inserts some CSS and JS to make images in Markdown documents which
are wider than the viewport, become shrink-to-fit. Clicking on these
toggles them between shrink-to-fit and full size.
Anyone who displays Markdown documents using LibWeb gets this
functionality for free! That's Browser, Help, and Welcome's README
display.
We don't need to notify the web views that some deeply nested iframe
has started loading a new URL (and we don't want it showing up in the
browser location bar either!)
We now implement the browsing context's "set active document" algorithm
from the spec, as well as the "discard" algorithm for browsing contexts
and documents.
It's not safe to capture `this` as a raw pointer here, since nothing
is guaranteed to keep the ResourceClient alive (even if the Resource
stays alive.)
This replaces the previous Web::ImageDecoding::Decoder interface.
While we're doing this, also move the SerenityOS implementation of this
interface from LibWebView to WebContent. That means we no longer have to
link with LibImageDecoderClient in applications that use a web view.
Instead of using Core::EventLoop and Core::Timer directly, LibWeb now
goes through a Web::Platform abstraction layer instead.
This will allow us to plug in Qt's event loop (and QTimer) over in
Ladybird, to avoid having to deal with multiple event loops.
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.
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.
