summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibWeb/HTML/GlobalEventHandlers.cpp
AgeCommit message (Collapse)Author
2022-09-24LibWeb: Move CallbackType from Bindings/ to WebIDL/Linus Groh
Let's stop putting generic types and AOs from the Web IDL spec into the Bindings namespace and directory in LibWeb, and instead follow our usual naming rules of 'directory = namespace = spec name'. The IDL namespace is already used by LibIDL, so Web::WebIDL seems like a good choice.
2022-09-06LibWeb: Move event listeners, handlers and callbacks to the GC heapAndreas Kling
This patch moves the following things to being GC-allocated: - Bindings::CallbackType - HTML::EventHandler - DOM::IDLEventListener - DOM::DOMEventListener - DOM::NodeFilter Note that we only use PlatformObject for things that might be exposed to web content. Anything that is only used internally inherits directly from JS::Cell instead, making them a bit more lightweight.
2022-06-29LibWeb: Implement WindowEventHandlersLuke Wilde
2022-06-29LibWeb: Only make certain <body> and <frameset> events apply to WindowLuke Wilde
Previously we forwarded all event handler attributes to Window from these two elements, however, we are only supposed to forward blur, error, focus, load, resize and scroll.
2022-03-17Libraries: Use default constructors/destructors in LibWebLenny Maiorani
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-02-16LibWeb: Separate "event listener" from "EventListener"Andreas Kling
I can't imagine how this happened, but it seems we've managed to conflate the "event listener" and "EventListener" concepts from the DOM specification in some parts of the code. We previously had two things: - DOM::EventListener - DOM::EventTarget::EventListenerRegistration DOM::EventListener was roughly the "EventListener" IDL type, and DOM::EventTarget::EventListenerRegistration was roughly the "event listener" concept. However, they were used interchangeably (and incorrectly!) in many places. After this patch, we now have: - DOM::IDLEventListener - DOM::DOMEventListener DOM::IDLEventListener is the "EventListener" IDL type, and DOM::DOMEventListener is the "event listener" concept. This patch also updates the addEventListener() and removeEventListener() functions to follow the spec more closely, along with the "inner invoke" function in our EventDispatcher.
2022-02-08LibWeb: Rewrite EventTarget to more closely match the specLuke Wilde
This isn't perfect (especially the global object situation in activate_event_handler), but I believe it's in a much more complete state now :^) This fixes the issue of crashing in prepare_for_ordinary_call with the `i < m_size` crash, as it now uses the IDL callback functions which requires the Environment Settings Object. The environment settings object for the callback is fetched at the time the callback is created, for example, WrapperGenerator gets the incumbent settings object for the callback at the time of wrapping. This allows us to remove passing in ScriptExecutionContext into EventTarget's constructor. With this, we can now drop ScriptExecutionContext.
2021-09-25LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObjectLinus Groh
The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-19LibWeb: Move `onfoo` attribute handling to EventTargetAndreas Kling
This logic was kept in the GlobalEventHandlers mixing for sharing between Document and HTMLElement, but there are other interfaces who need to support `onfoo` attribute event listeners as well.
2021-06-27LibJS: Rename ScriptFunction => OrdinaryFunctionObjectAndreas Kling
These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27LibJS: Rename Function => FunctionObjectAndreas Kling
2021-06-11LibJS: Use an enum class instead of 'bool is_generator'Ali Mohammad Pur
This avoid confusion in the order of the multiple boolean parameters that exist.
2021-06-11LibJS: Implement generator functions (only in bytecode mode)Ali Mohammad Pur
2021-04-23AK: Rename adopt() to adopt_ref()Andreas Kling
This makes it more symmetrical with adopt_own() (which is used to create a NonnullOwnPtr from the result of a naked new.)
2021-04-22Everything: Move to SPDX license identifiers in all files.Brian Gianforcaro
SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-02-23Everywhere: Rename ASSERT => VERIFYAndreas Kling
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-03LibWeb: Basic implementation of global event handlers :^)Andreas Kling
Document and HTMLElement now inherit from HTML::GlobalEventHandlers which allows them to support "onfoo" event handler attributes. These are assignable both via IDL attributes and content attributes. Event listeners constructed this way get a special "attribute" flag on them so we know which one to replace if you reassign them. This also allows them to coexist with EventTarget.addEventListener(). This is all a bit sloppy, but it works decently for a first cut. The Window object should also inherit GlobalEventHandlers, but since we don't generate it from IDL, I haven't taken that step here. Also this would be a lot nicer if we supported IDL mixins.