Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/HTML/StructuredSerialize.h

107 lines
3.2 KiB
C
Raw Normal View History

LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
/*
* Copyright (c) 2022, Daniel Ehrenberg <dan@littledan.dev>
* Copyright (c) 2022, Andrew Kaster <akaster@serenityos.org>
LibWeb: Move serialize_* methods outside scope of Serializer class These methods are useful independent of the class Serializer, so let's move their declarations to the header file and and outside the scope of the Serializer class.
2024-02-23 18:30:50 +01:00
* Copyright (c) 2024, Kenneth Myhra <kennethmyhra@serenityos.org>
LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
#include <AK/MemoryStream.h>
LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
#include <AK/Vector.h>
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
#include <LibIPC/Decoder.h>
#include <LibIPC/Encoder.h>
#include <LibIPC/Message.h>
LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
#include <LibJS/Forward.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
#include <LibWeb/Export.h>
LibWeb: Reorganize definitions and includes to avoid circular references This is necessary to avoid a circular reference when including Serializable.h in DOMException.h. This moves the definition of SerializationRecord, SerializationMemory, and DeserializationMemory into LibWeb/Forward.h so that Serializable.h only needs to include LibWeb/Forward.h.
2024-11-22 11:51:40 +01:00
#include <LibWeb/Forward.h>
#include <LibWeb/HTML/StructuredSerializeTypes.h>
LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
#include <LibWeb/WebIDL/ExceptionOr.h>
namespace Web::HTML {
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API TransferDataEncoder {
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
public:
explicit TransferDataEncoder();
explicit TransferDataEncoder(IPC::MessageBuffer&&);
template<typename T>
void encode(T const& value)
{
MUST(m_encoder.encode(value));
}
void append(SerializationRecord&&);
void extend(Vector<TransferDataEncoder>);
IPC::MessageBuffer const& buffer() const { return m_buffer; }
IPC::MessageBuffer take_buffer() { return move(m_buffer); }
private:
IPC::MessageBuffer m_buffer;
IPC::Encoder m_encoder;
};
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API TransferDataDecoder {
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
public:
explicit TransferDataDecoder(SerializationRecord const&);
explicit TransferDataDecoder(TransferDataEncoder&&);
template<typename T>
T decode()
{
static_assert(!IsSame<T, ByteBuffer>, "Use decode_buffer to handle OOM");
return MUST(m_decoder.decode<T>());
}
WebIDL::ExceptionOr<ByteBuffer> decode_buffer(JS::Realm&);
private:
IPC::MessageBuffer m_buffer;
FixedMemoryStream m_stream;
Queue<IPC::File> m_files;
IPC::Decoder m_decoder;
LibWeb: Add a Transferable interface to model the transferable property This property is only shared by MessagePort and a few Image related APIs but is important for the Structured{De}SerializeWithTransfer AOs.
2023-12-07 15:52:08 -07:00
};
struct SerializedTransferRecord {
SerializationRecord serialized;
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
Vector<TransferDataEncoder> transfer_data_holders;
LibWeb: Add a Transferable interface to model the transferable property This property is only shared by MessagePort and a few Image related APIs but is important for the Structured{De}SerializeWithTransfer AOs.
2023-12-07 15:52:08 -07:00
};
struct DeserializedTransferRecord {
JS::Value deserialized;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
Vector<GC::Root<JS::Object>> transferred_values;
LibWeb: Add a Transferable interface to model the transferable property This property is only shared by MessagePort and a few Image related APIs but is important for the Structured{De}SerializeWithTransfer AOs.
2023-12-07 15:52:08 -07:00
};
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
WebIDL::ExceptionOr<SerializationRecord> structured_serialize(JS::VM&, JS::Value);
WebIDL::ExceptionOr<SerializationRecord> structured_serialize_for_storage(JS::VM&, JS::Value);
WebIDL::ExceptionOr<SerializationRecord> structured_serialize_internal(JS::VM&, JS::Value, bool for_storage, SerializationMemory&);
LibWeb: Extract deserialization logic for {,object} primitives To avoid differing logic for deserializing similar types, move the logic into separate helpers. Also, adds security checks like VERIFY to avoid reading past the end of the serialized data. If we try to read past the end of the serialized data, either our program logic is wrong or our serialized data has somehow been corrupted. Therefore, at least currently, it is better to crash by VERIFYing.
2024-03-02 20:39:45 +01:00
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
WebIDL::ExceptionOr<JS::Value> structured_deserialize(JS::VM&, SerializationRecord const&, JS::Realm&, Optional<DeserializationMemory> = {});
WebIDL::ExceptionOr<JS::Value> structured_deserialize_internal(JS::VM&, TransferDataDecoder&, JS::Realm&, DeserializationMemory&);
LibWeb: Move deserialize_* methods outside scope of Deserializer class These methods are useful independent of the class Deserializer, so let's move their declarations to the header file and and outside the scope of the Deserializer class.
2024-02-22 18:28:34 +01:00
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
WEB_API WebIDL::ExceptionOr<SerializedTransferRecord> structured_serialize_with_transfer(JS::VM&, JS::Value, Vector<GC::Root<JS::Object>> const& transfer_list);
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
WebIDL::ExceptionOr<DeserializedTransferRecord> structured_deserialize_with_transfer(SerializedTransferRecord&, JS::Realm&);
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
WEB_API WebIDL::ExceptionOr<JS::Value> structured_deserialize_with_transfer_internal(TransferDataDecoder&, JS::Realm&);
LibWeb: Add initial implementation of structured clone This implementation only works for cloning Numbers, and does not try to do all the spec steps for structured serialize and deserialize. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2022-04-05 02:24:10 +02:00
}
LibWeb: Post all MessagePort messages over their LocalSockets This is to allow future changes to do cross-process MessagePorts in an implementation-agnostic way. Add some tests for this behavior. Delivering messages that were posted to a MessagePort just before it was transferred is not yet implemented still.
2023-12-19 15:28:56 -07:00
namespace IPC {
template<>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
WEB_API ErrorOr<void> encode(Encoder&, Web::HTML::TransferDataEncoder const&);
LibWeb: Post all MessagePort messages over their LocalSockets This is to allow future changes to do cross-process MessagePorts in an implementation-agnostic way. Add some tests for this behavior. Delivering messages that were posted to a MessagePort just before it was transferred is not yet implemented still.
2023-12-19 15:28:56 -07:00
template<>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
WEB_API ErrorOr<Web::HTML::TransferDataEncoder> decode(Decoder&);
LibWeb: Post all MessagePort messages over their LocalSockets This is to allow future changes to do cross-process MessagePorts in an implementation-agnostic way. Add some tests for this behavior. Delivering messages that were posted to a MessagePort just before it was transferred is not yet implemented still.
2023-12-19 15:28:56 -07:00
template<>
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
ErrorOr<void> encode(Encoder&, Web::HTML::SerializedTransferRecord const&);
LibWeb: Post all MessagePort messages over their LocalSockets This is to allow future changes to do cross-process MessagePorts in an implementation-agnostic way. Add some tests for this behavior. Delivering messages that were posted to a MessagePort just before it was transferred is not yet implemented still.
2023-12-19 15:28:56 -07:00
template<>
LibWeb+WebWorker: Use IPC mechanics for structured serialization Our structured serialization implementation had its own bespoke encoder and decoder to serialize JS values. It also used a u32 buffer under the hood, which made using its structures a bit awkward. We had previously worked around its data structures in transferable streams, which nested transfers of MessagePort instances. We basically had to add hooks into the MessagePort to route to the correct transfer receiving steps, and we could not invoke the correct AOs directly as the spec dictates. We now use IPC mechanics to encode and decode data. This works because, although we are encoding JS values, we are only ultimately encoding primitive and basic AK types. The resulting data structures actually enforce that we implement transferable streams exactly as the spec is worded (I had planned to do that in a separate commit, but the fallout of this patch actually required that change).
2025-07-17 09:51:04 -04:00
ErrorOr<Web::HTML::SerializedTransferRecord> decode(Decoder&);
LibWeb: Post all MessagePort messages over their LocalSockets This is to allow future changes to do cross-process MessagePorts in an implementation-agnostic way. Add some tests for this behavior. Delivering messages that were posted to a MessagePort just before it was transferred is not yet implemented still.
2023-12-19 15:28:56 -07:00
}
Reference in a new issue Copy permalink