Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Fetch/Fetching/PendingResponse.cpp

71 lines
1.9 KiB
C++
Raw Normal View History

LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
/*
* Copyright (c) 2022, Linus Groh <linusg@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibJS/Heap/Heap.h>
#include <LibJS/Runtime/VM.h>
#include <LibWeb/Fetch/Fetching/PendingResponse.h>
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
#include <LibWeb/Fetch/Infrastructure/HTTP/Requests.h>
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
#include <LibWeb/Platform/EventLoopPlugin.h>
namespace Web::Fetch::Fetching {
LibWeb: Put most LibWeb GC objects in type-specific heap blocks With this change, we now have ~1200 CellAllocators across both LibJS and LibWeb in a normal WebContent instance. This gives us a minimum heap size of 4.7 MiB in the scenario where we only have one cell allocated per type. Of course, in practice there will be many more of each type, so the effective overhead is quite a bit smaller than that in practice. I left a few types unconverted to this mechanism because I got tired of doing this. :^)
2023-11-19 19:47:52 +01:00
JS_DEFINE_ALLOCATOR(PendingResponse);
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
JS::NonnullGCPtr<PendingResponse> PendingResponse::create(JS::VM& vm, JS::NonnullGCPtr<Infrastructure::Request> request)
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
{
LibJS: Convert Heap::allocate{,_without_realm}() to NonnullGCPtr
2022-12-14 17:40:33 +00:00
return vm.heap().allocate_without_realm<PendingResponse>(request);
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
}
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
JS::NonnullGCPtr<PendingResponse> PendingResponse::create(JS::VM& vm, JS::NonnullGCPtr<Infrastructure::Request> request, JS::NonnullGCPtr<Infrastructure::Response> response)
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
{
LibJS: Convert Heap::allocate{,_without_realm}() to NonnullGCPtr
2022-12-14 17:40:33 +00:00
return vm.heap().allocate_without_realm<PendingResponse>(request, response);
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
}
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
PendingResponse::PendingResponse(JS::NonnullGCPtr<Infrastructure::Request> request, JS::GCPtr<Infrastructure::Response> response)
: m_request(request)
, m_response(response)
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
{
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
m_request->add_pending_response({}, *this);
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
}
void PendingResponse::visit_edges(JS::Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
LibWeb: Use JS::HeapFunction in Fetch::Fetching::PendingResponse This fixes a long-standing realm leak.
2024-04-03 11:49:50 +02:00
visitor.visit(m_callback);
LibWeb: Register PendingResponse with a Request to keep it alive This was an oversight from when I converted PendingResponse and various other classes from being ref-counted to GC-allocated last minute - no one takes care to keep all of them alive. Some are on the stack, and some might be captured in another PendingResponse's JS::SafeFunction, but ultimately, we need a better solution. Since a PendingResponse is *always* the result of someone having created a Request, let's just let that keep a list of each PendingResponse that has been created for it, and visit them until they are resolved. After that, they can be GC'd with no complaints.
2022-11-01 19:35:38 +00:00
visitor.visit(m_request);
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
visitor.visit(m_response);
}
void PendingResponse::when_loaded(Callback callback)
{
VERIFY(!m_callback);
LibWeb: Use JS::HeapFunction in Fetch::Fetching::PendingResponse This fixes a long-standing realm leak.
2024-04-03 11:49:50 +02:00
m_callback = JS::create_heap_function(heap(), move(callback));
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
if (m_response)
run_callback();
}
void PendingResponse::resolve(JS::NonnullGCPtr<Infrastructure::Response> response)
{
VERIFY(!m_response);
m_response = response;
if (m_callback)
run_callback();
}
LibJS: Handle both const and non-const Ts in Handle<T>::create() Again, the const-ness only really involves Heap-internal metadata, so the callers shouldn't care about mutations here.
2023-02-25 10:44:31 -07:00
void PendingResponse::run_callback()
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
{
VERIFY(m_callback);
VERIFY(m_response);
LibWeb+Browser+Ladybird: Use JS::SafeFunction for EventLoop callbacks This automatically protects captured objects from being GC'd before the callback runs.
2023-04-21 12:13:04 +01:00
Platform::EventLoopPlugin::the().deferred_invoke([this] {
LibWeb: Use JS::HeapFunction in Fetch::Fetching::PendingResponse This fixes a long-standing realm leak.
2024-04-03 11:49:50 +02:00
VERIFY(m_callback);
VERIFY(m_response);
m_callback->function()(*m_response);
LibWeb+Browser+Ladybird: Use JS::SafeFunction for EventLoop callbacks This automatically protects captured objects from being GC'd before the callback runs.
2023-04-21 12:13:04 +01:00
m_request->remove_pending_response({}, *this);
LibWeb: Implement most of the 'Fetching' AOs This implements the following operations from section 4 of the Fetch spec (https://fetch.spec.whatwg.org/#fetching): - Fetch - Main fetch - Fetch response handover - Scheme fetch - HTTP fetch - HTTP-redirect fetch - HTTP-network-or-cache fetch (without caching) It does *not* implement: - HTTP-network fetch - CORS-preflight fetch Instead, we let ResourceLoader handle the actual networking for now, which isn't ideal, but certainly enough to get enough functionality up and running for most websites to not complain.
2022-10-23 22:16:14 +01:00
});
}
}
Reference in a new issue Copy permalink