Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Bindings/Serializable.h

29 lines
896 B
C
Raw Normal View History

LibWeb: Add abstract class Serializable This adds the abstract class Serializable which platform objects defined as Serializable objects can implement to support their appropriate serialization and deserialization steps.
2024-02-23 17:25:37 +01:00
/*
* Copyright (c) 2024, Kenneth Myhra <kennethmyhra@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
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 abstract class Serializable This adds the abstract class Serializable which platform objects defined as Serializable objects can implement to support their appropriate serialization and deserialization steps.
2024-02-23 17:25:37 +01:00
namespace Web::Bindings {
// https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects
class Serializable {
public:
virtual ~Serializable() = default;
LibWeb: Use enum for serialization and reimplement interface exposure Our currently implementation of structured serialization has a design flaw, where if the serialized/transferred type was not used in the destination realm, it would not be seen as exposed and thus we would not re-create the type on the other side. This is very common, for example, transferring a MessagePort to a just inserted iframe, or the just inserted iframe transferring a MessagePort to it's parent. This is what Google reCAPTCHA does. This flaw occurred due to relying on lazily populated HashMaps of constructors, namespaces and interfaces. This commit changes it so that per-type "is exposed" implementations are generated. Since it no longer relies on interface name strings, this commit changes serializable types to indicate their type with an enum, in line with how transferrable types indicate their type. This makes Google reCAPTCHA work on https://www.google.com/recaptcha/api2/demo It currently doesn't work on non-Google origins due to a separate same-origin policy bug.
2025-07-14 17:15:09 +01:00
virtual HTML::SerializeType serialize_type() const = 0;
LibWeb: Add abstract class Serializable This adds the abstract class Serializable which platform objects defined as Serializable objects can implement to support their appropriate serialization and deserialization steps.
2024-02-23 17:25:37 +01:00
// https://html.spec.whatwg.org/multipage/structured-data.html#serialization-steps
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
virtual WebIDL::ExceptionOr<void> serialization_steps(HTML::TransferDataEncoder&, bool for_storage, HTML::SerializationMemory&) = 0;
LibWeb: Add abstract class Serializable This adds the abstract class Serializable which platform objects defined as Serializable objects can implement to support their appropriate serialization and deserialization steps.
2024-02-23 17:25:37 +01:00
// https://html.spec.whatwg.org/multipage/structured-data.html#deserialization-steps
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
virtual WebIDL::ExceptionOr<void> deserialization_steps(HTML::TransferDataDecoder&, HTML::DeserializationMemory&) = 0;
LibWeb: Add abstract class Serializable This adds the abstract class Serializable which platform objects defined as Serializable objects can implement to support their appropriate serialization and deserialization steps.
2024-02-23 17:25:37 +01:00
};
}
Reference in a new issue Copy permalink