Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-22 00:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Geometry/DOMQuad.h

65 lines
2.1 KiB
C
Raw Normal View History

LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
/*
* Copyright (c) 2023, Bastiaan van der Plaat <bastiaan.v.d.plaat@gmail.com>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibWeb/Bindings/PlatformObject.h>
#include <LibWeb/Geometry/DOMPoint.h>
#include <LibWeb/Geometry/DOMRect.h>
#include <LibWeb/Geometry/DOMRectReadOnly.h>
namespace Web::Geometry {
// https://drafts.fxtf.org/geometry/#dictdef-domquadinit
struct DOMQuadInit {
DOMPointInit p1;
DOMPointInit p2;
DOMPointInit p3;
DOMPointInit p4;
};
// https://drafts.fxtf.org/geometry/#domquad
LibWeb: Add {,de}serialization steps for DOMQuad
2024-03-12 21:08:46 +01:00
class DOMQuad
: public Bindings::PlatformObject
, public Bindings::Serializable {
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
WEB_PLATFORM_OBJECT(DOMQuad, Bindings::PlatformObject);
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
GC_DECLARE_ALLOCATOR(DOMQuad);
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
public:
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
static GC::Ref<DOMQuad> construct_impl(JS::Realm&, DOMPointInit const& p1, DOMPointInit const& p2, DOMPointInit const& p3, DOMPointInit const& p4);
static GC::Ref<DOMQuad> create(JS::Realm& realm);
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
virtual ~DOMQuad() override;
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
static GC::Ref<DOMQuad> from_rect(JS::VM&, DOMRectInit const&);
static GC::Ref<DOMQuad> from_quad(JS::VM&, DOMQuadInit const&);
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
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
GC::Ref<DOMPoint> p1() const { return m_p1; }
GC::Ref<DOMPoint> p2() const { return m_p2; }
GC::Ref<DOMPoint> p3() const { return m_p3; }
GC::Ref<DOMPoint> p4() const { return m_p4; }
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
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
GC::Ref<DOMRect> get_bounds() const;
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
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 override { return HTML::SerializeType::DOMQuad; }
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&) override;
virtual WebIDL::ExceptionOr<void> deserialization_steps(HTML::TransferDataDecoder&, HTML::DeserializationMemory&) override;
LibWeb: Add {,de}serialization steps for DOMQuad
2024-03-12 21:08:46 +01:00
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
private:
DOMQuad(JS::Realm&, DOMPointInit const& p1, DOMPointInit const& p2, DOMPointInit const& p3, DOMPointInit const& p4);
LibWeb: Add {,de}serialization steps for DOMQuad
2024-03-12 21:08:46 +01:00
explicit DOMQuad(JS::Realm&);
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
virtual void initialize(JS::Realm&) override;
virtual void visit_edges(Cell::Visitor&) override;
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
GC::Ref<DOMPoint> m_p1;
GC::Ref<DOMPoint> m_p2;
GC::Ref<DOMPoint> m_p3;
GC::Ref<DOMPoint> m_p4;
LibWeb: Add DOMQuad and text tests
2023-08-20 22:03:41 +02:00
};
}
Reference in a new issue Copy permalink