Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Loader/Resource.h

103 lines
2.9 KiB
C
Raw Normal View History

LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
*/
#pragma once
#include <AK/ByteBuffer.h>
#include <AK/HashMap.h>
#include <AK/HashTable.h>
#include <AK/Noncopyable.h>
#include <AK/RefCounted.h>
#include <AK/URL.h>
LibWeb: Protect ourselves during ResourceClient iteration Notifying a Resource's clients may lead to arbitrary JS execution, so we can't rely on the ResourceClient pointers remaining valid. Use WeakPtr to avoid this problem.
2020-06-01 22:09:38 +02:00
#include <AK/WeakPtr.h>
#include <AK/Weakable.h>
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
#include <LibGfx/Forward.h>
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
#include <LibWeb/Forward.h>
LibWeb: Add a naive Resource cache This patch introduces a caching mechanism in ResourceLoader. It's keyed on a LoadRequest object which is what you provide to load_resource() when you want to load a resource. We currently never prune the cache, so resources will stay in there forever. This is obviously not gonna stay that way, but we're just getting started here. :^) This should drastically reduce the number of requests when loading some sites (like Twitter) that reuse the same images over and over.
2020-06-01 21:58:29 +02:00
#include <LibWeb/Loader/LoadRequest.h>
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
namespace Web {
class ResourceClient;
class Resource : public RefCounted<Resource> {
AK_MAKE_NONCOPYABLE(Resource);
AK_MAKE_NONMOVABLE(Resource);
public:
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
enum class Type {
Generic,
Image,
};
static NonnullRefPtr<Resource> create(Badge<ResourceLoader>, Type, const LoadRequest&);
virtual ~Resource();
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Fix mismatching Resource subclass types This was a confusing bug: ImageStyleValue loaded its image resource as a Generic resource, while HTMLImageElement loaded as Image. This patch fixes the issue and adds an assertion to verify that we only share resources that have the same C++ client class type.
2020-06-05 23:32:23 +02:00
Type type() const { return m_type; }
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
bool is_loaded() const { return m_loaded; }
bool is_failed() const { return m_failed; }
const String& error() const { return m_error; }
AK+Userland: Remove nullability feature for the ByteBuffer type Nobody seems to use this particular feature, in fact there were some bugs which were uncovered by removing operator bool.
2021-05-16 08:47:46 +02:00
bool has_encoded_data() const { return !m_encoded_data.is_empty(); }
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Add the Web::URL namespace and move URLEncoder to it 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.
2021-09-13 00:33:23 +03:00
const AK::URL& url() const { return m_request.url(); }
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
const ByteBuffer& encoded_data() const { return m_encoded_data; }
LibWeb: Turn FrameLoader into a ResourceClient We now use the new resource-based loader for the main resource in each Frame. This gives us access to caching and sharing. :^)
2020-06-06 13:38:08 +02:00
const HashMap<String, String, CaseInsensitiveStringTraits>& response_headers() const { return m_response_headers; }
LibWeb: Ignore Location headers unless the response status code is 3xx 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.
2022-02-12 15:42:48 +02:00
[[nodiscard]] Optional<u32> status_code() const { return m_status_code; }
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
void register_client(Badge<ResourceClient>, ResourceClient&);
void unregister_client(Badge<ResourceClient>, ResourceClient&);
LibWeb: Change Resource's m_encoding to Optional<String> This modifies the Resource class to use Optional<String> for the encoding. If the encoding is unknown, the Optional will not have a value (instead of using the null state of the String class). It also implements a has_encoding() instance method and modifies the callers of Resource::encoding() to use the new API.
2021-05-12 10:21:00 +02:00
bool has_encoding() const { return m_encoding.has_value(); }
const Optional<String>& encoding() const { return m_encoding; }
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
const String& mime_type() const { return m_mime_type; }
LibWeb: Protect ourselves during ResourceClient iteration Notifying a Resource's clients may lead to arbitrary JS execution, so we can't rely on the ResourceClient pointers remaining valid. Use WeakPtr to avoid this problem.
2020-06-01 22:09:38 +02:00
void for_each_client(Function<void(ResourceClient&)>);
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
void did_load(Badge<ResourceLoader>, ReadonlyBytes data, const HashMap<String, String, CaseInsensitiveStringTraits>& headers, Optional<u32> status_code);
void did_fail(Badge<ResourceLoader>, const String& error, Optional<u32> status_code);
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
protected:
explicit Resource(Type, const LoadRequest&);
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
private:
LibWeb: Add a naive Resource cache This patch introduces a caching mechanism in ResourceLoader. It's keyed on a LoadRequest object which is what you provide to load_resource() when you want to load a resource. We currently never prune the cache, so resources will stay in there forever. This is obviously not gonna stay that way, but we're just getting started here. :^) This should drastically reduce the number of requests when loading some sites (like Twitter) that reuse the same images over and over.
2020-06-01 21:58:29 +02:00
LoadRequest m_request;
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
ByteBuffer m_encoded_data;
LibWeb: Share decoded images at the Resource level :^) This patch adds ImageResource as a subclass of Resource. This new class also keeps a Gfx::ImageDecoder so that we can share decoded bitmaps between all clients of an image resource inside LibWeb. With this, we now share both encoded and decoded data for images. :^) I had to change how the purgeable-volatile flag is updated to keep the volatile-images-outside-the-visible-viewport optimization working. HTMLImageElement now inherits from ImageResourceClient (a subclass of ResourceClient with additional image-specific stuff) and informs its ImageResource about whether it's inside the viewport or outside. This is pretty awesome! :^)
2020-06-02 20:27:26 +02:00
Type m_type { Type::Generic };
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
bool m_loaded { false };
bool m_failed { false };
String m_error;
LibWeb: Change Resource's m_encoding to Optional<String> This modifies the Resource class to use Optional<String> for the encoding. If the encoding is unknown, the Optional will not have a value (instead of using the null state of the String class). It also implements a has_encoding() instance method and modifies the callers of Resource::encoding() to use the new API.
2021-05-12 10:21:00 +02:00
Optional<String> m_encoding;
LibWeb: Let Resource figure out its own encoding and MIME type Also, if the request URL is a data: URL, use the MIME type from the URL itself if available. This makes it possible to load arbitrary MIME type data: URLs in the browser :^)
2020-06-06 14:02:43 +02:00
String m_mime_type;
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
HashMap<String, String, CaseInsensitiveStringTraits> m_response_headers;
LibWeb: Pass optional status code to ResourceLoader callbacks This is needed for XMLHttpRequest, and will certainly be useful for other things, too.
2021-04-03 15:11:36 +02:00
Optional<u32> m_status_code;
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
HashTable<ResourceClient*> m_clients;
};
LibWeb: Protect ourselves during ResourceClient iteration Notifying a Resource's clients may lead to arbitrary JS execution, so we can't rely on the ResourceClient pointers remaining valid. Use WeakPtr to avoid this problem.
2020-06-01 22:09:38 +02:00
class ResourceClient : public Weakable<ResourceClient> {
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
public:
virtual ~ResourceClient();
virtual void resource_did_load() { }
virtual void resource_did_fail() { }
protected:
LibWeb: Fix mismatching Resource subclass types This was a confusing bug: ImageStyleValue loaded its image resource as a Generic resource, while HTMLImageElement loaded as Image. This patch fixes the issue and adds an assertion to verify that we only share resources that have the same C++ client class type.
2020-06-05 23:32:23 +02:00
virtual Resource::Type client_type() const { return Resource::Type::Generic; }
LibWeb: Start building a new Resource class to share more resources A Resource represents a resource that we're loading, have loaded or will soon load. Basically, it's a downloadable resource that can be shared by multiple clients. A typical usecase is multiple <img> elements with the same src. In a future patch, we will try to make sure that those <img> elements get the same Resource if possible. This will reduce network usage, memory usage, and CPU usage. :^) For now, this first patch simply introduces the mechanism. You get a Resource by calling ResourceLoader::load_resource(). To get notified about changes to a Resource's load status, you inherit from ResourceClient and implement the callbacks you're interested in. This patch turns HTMLImageElement into a ResourceClient.
2020-06-01 21:33:23 +02:00
Resource* resource() { return m_resource; }
const Resource* resource() const { return m_resource; }
void set_resource(Resource*);
private:
RefPtr<Resource> m_resource;
};
}
Reference in a new issue Copy permalink