dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/HTML/MessageEvent.h

67 lines
2.7 KiB
C
Raw Permalink Normal View History

LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
/*
* Copyright (c) 2021, Dex♪ <dexes.ttp@gmail.com>
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb/HTML: Store MessageEvent source as Ref not Root
2026-02-16 11:28:08 -03:00
* Copyright (c) 2026, Sam Atkins <sam@ladybird.org>
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb: Port MessageEvent to new String
2023-03-05 06:33:56 -03:00
#include <AK/FlyString.h>
LibWeb: Unify WebIDL C++ type generation Represent WebIDL C++ types with a single CppType model that tracks nullability, optional presence, and contained storage. GC-like values now use GC::Ref/GC::Ptr directly, while containers choose "plain", "Root", or "Conservative" container types depending on what they contain. For example, sequence<Element> becomes a RootVector of GC::Ref values, while sequence<SomeDictionary> becomes a ConservativeVector only when the dictionary contains GC-like values. This moves the generated bindings away from wrapping GC values in GC::Root by default. This has broad fallout as the types passed to interfaces for GC objects changes almost fully across the board.
2026-05-20 15:58:46 -03:00
#include <LibGC/RootVector.h>
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
#include <LibWeb/DOM/Event.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 23:35:33 -03:00
#include <LibWeb/Export.h>
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
namespace Web::HTML {
LibWeb: Add MessageEvent.source
2023-11-06 17:11:58 -03:00
// FIXME: Include ServiceWorker
LibWeb/HTML: Add some spec links to MessageEvent header
2026-03-16 14:36:36 -03:00
// https://html.spec.whatwg.org/multipage/comms.html#messageeventsource
LibWeb: Unify WebIDL C++ type generation Represent WebIDL C++ types with a single CppType model that tracks nullability, optional presence, and contained storage. GC-like values now use GC::Ref/GC::Ptr directly, while containers choose "plain", "Root", or "Conservative" container types depending on what they contain. For example, sequence<Element> becomes a RootVector of GC::Ref values, while sequence<SomeDictionary> becomes a ConservativeVector only when the dictionary contains GC-like values. This moves the generated bindings away from wrapping GC values in GC::Root by default. This has broad fallout as the types passed to interfaces for GC objects changes almost fully across the board.
2026-05-20 15:58:46 -03:00
using MessageEventSource = Variant<GC::Ref<WindowProxy>, GC::Ref<MessagePort>>;
using NullableMessageEventSource = Variant<GC::Ref<WindowProxy>, GC::Ref<MessagePort>, Empty>;
LibWeb: Add MessageEvent.source
2023-11-06 17:11:58 -03:00
LibWeb/HTML: Add some spec links to MessageEvent header
2026-03-16 14:36:36 -03:00
// https://html.spec.whatwg.org/multipage/comms.html#messageevent
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 23:35:33 -03:00
class WEB_API MessageEvent : public DOM::Event {
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 08:42:07 -03:00
WEB_PLATFORM_OBJECT(MessageEvent, DOM::Event);
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-14 12:01:23 -03:00
GC_DECLARE_ALLOCATOR(MessageEvent);
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
public:
LibWeb: Unify WebIDL C++ type generation Represent WebIDL C++ types with a single CppType model that tracks nullability, optional presence, and contained storage. GC-like values now use GC::Ref/GC::Ptr directly, while containers choose "plain", "Root", or "Conservative" container types depending on what they contain. For example, sequence<Element> becomes a RootVector of GC::Ref values, while sequence<SomeDictionary> becomes a ConservativeVector only when the dictionary contains GC-like values. This moves the generated bindings away from wrapping GC values in GC::Root by default. This has broad fallout as the types passed to interfaces for GC objects changes almost fully across the board.
2026-05-20 15:58:46 -03:00
[[nodiscard]] static GC::Ref<MessageEvent> create(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const&);
LibWeb/Bindings: Generate struct definitions from IDL dictionaries Previously we were inconsistent by generating code for enum definitions but not generating code for dictionaries. With future changes to the IDL generator to expose helpers to convert to and from IDL values this produced circular depdendencies. To solve this problem, also generate the dictionary definitions in bindings headers.
2026-05-01 14:01:23 -03:00
[[nodiscard]] static GC::Ref<MessageEvent> create(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const&, URL::Origin const&);
static WebIDL::ExceptionOr<GC::Ref<MessageEvent>> construct_impl(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const&);
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
LibWeb/Bindings: Generate struct definitions from IDL dictionaries Previously we were inconsistent by generating code for enum definitions but not generating code for dictionaries. With future changes to the IDL generator to expose helpers to convert to and from IDL values this produced circular depdendencies. To solve this problem, also generate the dictionary definitions in bindings headers.
2026-05-01 14:01:23 -03:00
MessageEvent(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const& event_init);
MessageEvent(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const& event_init, URL::Origin const&);
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
virtual ~MessageEvent() override;
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
JS::Value data() const { return m_data; }
LibWeb/HTML: Teach MessageEvent to work with origins Corresponds to whatwg/html@748b068c7c Which fixes the Origin.from() handling for MessageEvent's.
2026-03-17 02:55:56 -03:00
String origin() const;
LibWeb: Port MessageEvent to new String
2023-03-05 06:33:56 -03:00
String const& last_event_id() const { return m_last_event_id; }
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-14 12:01:23 -03:00
GC::Ref<JS::Object> ports() const;
LibWeb/HTML: Store MessageEvent source as Ref not Root
2026-02-16 11:28:08 -03:00
LibWeb+IDLGenerators: Support nullable union types
2026-02-17 11:57:03 -03:00
NullableMessageEventSource source() const;
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
LibWeb/HTML: Implement the Origin interface See: https://github.com/whatwg/html/commit/68909b2
2025-12-07 10:19:54 -03:00
virtual Optional<URL::Origin> extract_an_origin() const override;
LibWeb: Unify WebIDL C++ type generation Represent WebIDL C++ types with a single CppType model that tracks nullability, optional presence, and contained storage. GC-like values now use GC::Ref/GC::Ptr directly, while containers choose "plain", "Root", or "Conservative" container types depending on what they contain. For example, sequence<Element> becomes a RootVector of GC::Ref values, while sequence<SomeDictionary> becomes a ConservativeVector only when the dictionary contains GC-like values. This moves the generated bindings away from wrapping GC values in GC::Root by default. This has broad fallout as the types passed to interfaces for GC objects changes almost fully across the board.
2026-05-20 15:58:46 -03:00
void init_message_event(String const& type, bool bubbles, bool cancelable, JS::Value data, String const& origin, String const& last_event_id, NullableMessageEventSource source, GC::RootVector<GC::Ref<MessagePort>> const& ports);
LibWeb: Implement MessageEvent.initMessageEvent This fixes wpt/html/webappapis/scripting/events/messageevent-constructor.https.html
2024-07-09 15:43:51 -03:00
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
private:
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 03:41:28 -03:00
virtual void initialize(JS::Realm&) override;
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
virtual void visit_edges(Cell::Visitor&) override;
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
LibWeb/Bindings: Generate struct definitions from IDL dictionaries Previously we were inconsistent by generating code for enum definitions but not generating code for dictionaries. With future changes to the IDL generator to expose helpers to convert to and from IDL values this produced circular depdendencies. To solve this problem, also generate the dictionary definitions in bindings headers.
2026-05-01 14:01:23 -03:00
MessageEvent(JS::Realm&, FlyString const& event_name, Bindings::MessageEventInit const& event_init, Variant<URL::Origin, String, Empty>);
LibWeb/HTML: Store MessageEvent source as Ref not Root
2026-02-16 11:28:08 -03:00
LibWeb: Make DOM::Event and all its subclasses GC-allocated
2022-08-08 17:29:40 -03:00
JS::Value m_data;
LibWeb/HTML: Teach MessageEvent to work with origins Corresponds to whatwg/html@748b068c7c Which fixes the Origin.from() handling for MessageEvent's.
2026-03-17 02:55:56 -03:00
// https://html.spec.whatwg.org/multipage/comms.html#concept-messageevent-origin
// Each MessageEvent has an origin (an origin, a string, or null), initially null.
Variant<URL::Origin, String, Empty> m_origin;
LibWeb: Port MessageEvent to new String
2023-03-05 06:33:56 -03:00
String m_last_event_id;
LibWeb: Unify WebIDL C++ type generation Represent WebIDL C++ types with a single CppType model that tracks nullability, optional presence, and contained storage. GC-like values now use GC::Ref/GC::Ptr directly, while containers choose "plain", "Root", or "Conservative" container types depending on what they contain. For example, sequence<Element> becomes a RootVector of GC::Ref values, while sequence<SomeDictionary> becomes a ConservativeVector only when the dictionary contains GC-like values. This moves the generated bindings away from wrapping GC values in GC::Root by default. This has broad fallout as the types passed to interfaces for GC objects changes almost fully across the board.
2026-05-20 15:58:46 -03:00
NullableMessageEventSource m_source;
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-14 12:01:23 -03:00
Vector<GC::Ref<JS::Object>> m_ports;
mutable GC::Ptr<JS::Array> m_ports_array;
LibWeb: Add WebSocket bindings The WebSocket bindings match the original specification from the WHATWG living standard, but do not match the later update of the standard that involves FETCH. The FETCH update will be handled later since the changes would also affect XMLHttpRequest.
2021-04-24 08:54:24 -03:00
};
}
Reference in a new issue Copy permalink