Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/HTML/FormAssociatedElement.h

281 lines
17 KiB
C
Raw Normal View History

LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2021, Andreas Kling <andreas@ladybird.org>
Meta: Update my email address everywhere
2024-11-01 12:14:53 +01:00
* Copyright (c) 2024, Jelle Raaijmakers <jelle@ladybird.org>
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
*
Everything: Move to SPDX license identifiers in all files. 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-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
*/
#pragma once
LibWeb: Port HTMLInputElement from DeprecatedString to String And dealing with the fallout of doing so. I am not 100% sure that it is safe for us to be treating Strings in the value sanitization algorithm in all cases as if they are ASCII, but this commit does not change any existing behaviour there.
2023-11-20 20:32:40 +13:00
#include <AK/String.h>
LibJS+LibWeb: Use GC::Weak instead of AK::WeakPtr for GC-allocated types This makes some common types like JS::Object smaller (by 8 bytes) and yields a minor speed improvement on many benchmarks.
2025-10-16 11:13:54 +02:00
#include <LibGC/Weak.h>
LibWeb: Implement setRangeText for input and textarea elements This method replaces range of text in its respective element with a new string
2024-08-30 17:22:58 +01:00
#include <LibWeb/Bindings/HTMLFormElementPrototype.h>
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
#include <LibWeb/DOM/InputEventsTarget.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
#include <LibWeb/Export.h>
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
#include <LibWeb/Forward.h>
HTML: Put HTMLTextAreaElement selection helpers in FormAssociatedElement This will allow us to more closely follow the spec and share these functions with HTMLInputElement.
2024-07-28 15:55:09 +12:00
#include <LibWeb/WebIDL/Types.h>
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
namespace Web::HTML {
Everywhere: Fix a bunch of typos
2022-05-29 11:50:10 +01:00
// Form-associated elements should invoke this macro to inject overridden FormAssociatedElement and HTMLElement
// methods as needed. If your class wished to override an HTMLElement method that is overridden here, use the
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
// following methods instead:
//
// HTMLElement::inserted() -> Use form_associated_element_was_inserted()
// HTMLElement::removed_from() -> Use form_associated_element_was_removed()
//
LibWeb: Consolidate the attribute change handlers We currently have 2 virtual methods to inform DOM::Element subclasses when an attribute has changed, one of which is spec-compliant. This patch removes the non-compliant variant.
2024-11-14 08:14:16 -05:00
#define FORM_ASSOCIATED_ELEMENT(ElementBaseClass, ElementClass) \
private: \
virtual HTMLElement& form_associated_element_to_html_element() override \
{ \
static_assert(IsBaseOf<HTMLElement, ElementClass>); \
return *this; \
} \
\
virtual void inserted() override \
{ \
ElementBaseClass::inserted(); \
form_node_was_inserted(); \
form_associated_element_was_inserted(); \
} \
\
LibWeb: Pass old parent's root to Node::removed_from() This will allow nodes to access the root they've just been removed from.
2025-01-23 17:37:18 +01:00
virtual void removed_from(DOM::Node* old_parent, DOM::Node& old_root) override \
LibWeb: Consolidate the attribute change handlers We currently have 2 virtual methods to inform DOM::Element subclasses when an attribute has changed, one of which is spec-compliant. This patch removes the non-compliant variant.
2024-11-14 08:14:16 -05:00
{ \
LibWeb: Pass old parent's root to Node::removed_from() This will allow nodes to access the root they've just been removed from.
2025-01-23 17:37:18 +01:00
ElementBaseClass::removed_from(old_parent, old_root); \
LibWeb: Consolidate the attribute change handlers We currently have 2 virtual methods to inform DOM::Element subclasses when an attribute has changed, one of which is spec-compliant. This patch removes the non-compliant variant.
2024-11-14 08:14:16 -05:00
form_node_was_removed(); \
LibWeb: Pass old parent's root to Node::removed_from() This will allow nodes to access the root they've just been removed from.
2025-01-23 17:37:18 +01:00
form_associated_element_was_removed(old_parent); \
LibWeb: Consolidate the attribute change handlers We currently have 2 virtual methods to inform DOM::Element subclasses when an attribute has changed, one of which is spec-compliant. This patch removes the non-compliant variant.
2024-11-14 08:14:16 -05:00
} \
\
LibWeb: Implement 'State-preserving atomic move integration' This was recently added to both the HTML and DOM specifications, introducing the new moveBefore DOM API, as well as the new internal 'removing steps'. See: * https://github.com/whatwg/html/commit/432e8fb * https://github.com/whatwg/dom/commit/eaf2ac7
2025-03-08 12:45:26 +13:00
virtual void moved_from(GC::Ptr<DOM::Node> old_parent) override \
{ \
ElementBaseClass::moved_from(old_parent); \
form_node_was_moved(); \
form_associated_element_was_moved(old_parent); \
} \
\
LibWeb: Consolidate the attribute change handlers We currently have 2 virtual methods to inform DOM::Element subclasses when an attribute has changed, one of which is spec-compliant. This patch removes the non-compliant variant.
2024-11-14 08:14:16 -05:00
virtual void attribute_changed(FlyString const& name, Optional<String> const& old_value, Optional<String> const& value, Optional<FlyString> const& namespace_) override \
{ \
ElementBaseClass::attribute_changed(name, old_value, value, namespace_); \
form_node_attribute_changed(name, value); \
LibWeb/HTML: Sanitize email input with multiple attribute This implements the missing part of the value sanitization algorithm for email inputs with the multiple attribute.
2025-07-22 00:58:28 +02:00
form_associated_element_attribute_changed(name, old_value, value, namespace_); \
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
}
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#selection-direction
enum class SelectionDirection {
Forward,
Backward,
None,
};
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API FormAssociatedElement {
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
public:
HTMLFormElement* form() { return m_form; }
HTMLFormElement const* form() const { return m_form; }
void set_form(HTMLFormElement*);
LibWeb: Reset form association when any element with an ID changes When an element with an ID is added to or removed from the DOM, or if an ID is added, removed, or changed, then we must reset the form owner of all form-associated elements who have a form attribute. We do this in 2 steps, using the DOM document as the messenger to handle these changes: 1. All form-associated elements with a form attribute are stored on the document. If the form attribute is removed, the element is removed from that list as well. 2. When a DOM element with an ID undergoes any of the aforementioned changes, it notifies the document of the change. The document then forwards that change to the stored form-associated elements.
2024-02-03 10:29:26 -05:00
void element_id_changed(Badge<DOM::Document>);
void element_with_id_was_added_or_removed(Badge<DOM::Document>);
LibWeb: Move enabled() to FormAssociatedElement and follow the spec
2022-03-01 20:59:46 +00:00
bool enabled() const;
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
void set_parser_inserted(Badge<HTMLParser>);
LibWeb: Associate form elements with a form in parsing and dynamically This makes it available for all form associated elements and not just select and input elements. It also makes it more spec compliant, especially around the form attribute. The main thing missing is re-associating form elements with a form attribute when the form attribute changes or an element with an ID is inserted/removed or has its ID changed.
2022-03-01 21:10:48 +00:00
LibWeb: Add form associated element categories
2022-03-01 21:03:30 +00:00
// https://html.spec.whatwg.org/multipage/forms.html#category-listed
virtual bool is_listed() const { return false; }
// https://html.spec.whatwg.org/multipage/forms.html#category-submit
virtual bool is_submittable() const { return false; }
// https://html.spec.whatwg.org/multipage/forms.html#category-reset
virtual bool is_resettable() const { return false; }
// https://html.spec.whatwg.org/multipage/forms.html#category-autocapitalize
LibWeb: Update `is_autocapitalize_inheriting` method name with spec This was changed when the autocorrect attribute was introduced: https://github.com/whatwg/html/commit/7bab05a
2025-05-26 16:21:29 +12:00
virtual bool is_autocapitalize_and_autocorrect_inheriting() const { return false; }
LibWeb: Add form associated element categories
2022-03-01 21:03:30 +00:00
LibWeb: Fix up constructing the form entry list In particular: - Don't include none submitter buttons. - Use type_state() instead type() to avoid direct string comparisons - Support the hidden _charset_ input - Get form associated element's value directly instead of via the value attribute - Split line break normalization into a separate function so that it can also be used by form submission.
2023-06-18 15:08:15 +01:00
// https://html.spec.whatwg.org/multipage/forms.html#concept-button
virtual bool is_button() const { return false; }
// https://html.spec.whatwg.org/multipage/forms.html#concept-submit-button
virtual bool is_submit_button() const { return false; }
LibWeb: Implement HTMLFormElement::checkValidity (constraint validation) This change implements the requirements from the HTML spec at https://html.spec.whatwg.org/#statically-validate-the-constraints and https://html.spec.whatwg.org/#dom-form-checkvalidity — the parts of the HTML constraint validation API (aka “client-side form validation”) https://html.spec.whatwg.org/#the-constraint-validation-api for HTMLFormElement itself — as well as the code for the requirements at https://html.spec.whatwg.org/#check-validity-steps, which are the shared requirements for the checkValidity method for individual form controls.
2025-02-22 22:14:44 +09:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#check-validity-steps
bool check_validity_steps();
LibWeb/HTML: Implement `report_validity` This implements the previously stubbed out `report_validity` method. The specification is not very clear on how to exactly report the validity. For now, we bring the first visible invalid control into view and focus it. In the future, however, it would make sense to support more complex scenarios and be more aligned with the other implementations.
2025-05-03 19:52:01 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#report-validity-steps
bool report_validity_steps();
LibWeb: Reference multipage spec for form element constraints
2025-02-05 17:03:11 -07:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#candidate-for-constraint-validation
LibWeb: Implement CSS validity pseudo-classes
2025-02-02 20:41:23 +01:00
bool is_candidate_for_constraint_validation() const;
LibWeb: Reference multipage spec for form element constraints
2025-02-05 17:03:11 -07:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-fv-valid
LibWeb: Implement CSS validity pseudo-classes
2025-02-02 20:41:23 +01:00
bool satisfies_its_constraints() const;
LibWeb: Implement 'no-validate state' concept
2025-05-04 16:25:02 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-fs-novalidate
bool novalidate_state() const;
LibWeb: Reference multipage spec for form element constraints
2025-02-05 17:03:11 -07:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure/#definitions
LibWeb: Implement CSS validity pseudo-classes
2025-02-02 20:41:23 +01:00
virtual bool suffering_from_being_missing() const { return false; }
virtual bool suffering_from_a_type_mismatch() const { return false; }
virtual bool suffering_from_a_pattern_mismatch() const { return false; }
bool suffering_from_being_too_long() const;
bool suffering_from_being_too_short() const;
virtual bool suffering_from_an_underflow() const { return false; }
virtual bool suffering_from_an_overflow() const { return false; }
virtual bool suffering_from_a_step_mismatch() const { return false; }
virtual bool suffering_from_bad_input() const { return false; }
bool suffering_from_a_custom_error() const;
LibWeb: Port the FormAssociatedElement value to UTF-16 This porting effort makes it pretty clear we will want a UTF-16-aware GenericLexer. But for now, we can actually make ASCII assumptions about what we are parsing, and act accordingly.
2025-07-26 12:19:56 -04:00
virtual Utf16String value() const { return {}; }
LibWeb/HTML: Implement and use "optional value" Corresponds to https://github.com/whatwg/html/commit/f3444c23ffba2eaba715db1c609253e5488fb530 Also import a test.
2025-07-08 11:28:10 +01:00
virtual Optional<String> optional_value() const { VERIFY_NOT_REACHED(); }
LibWeb: Fix up constructing the form entry list In particular: - Don't include none submitter buttons. - Use type_state() instead type() to avoid direct string comparisons - Support the hidden _charset_ input - Get form associated element's value directly instead of via the value attribute - Split line break normalization into a separate function so that it can also be used by form submission.
2023-06-18 15:08:15 +01:00
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
virtual HTMLElement& form_associated_element_to_html_element() = 0;
HTML: Add const qualified form_associated_element_to_html_element Put the const cast in a common location to make the helper more convenient to use.
2024-07-28 15:52:59 +12:00
HTMLElement const& form_associated_element_to_html_element() const { return const_cast<FormAssociatedElement&>(*this).form_associated_element_to_html_element(); }
LibWeb: Register FormAssociatedElement with their owner form This will eventually allow us to implement HTMLFormControlsCollection.
2021-04-20 23:34:49 +02:00
LibWeb: Implement HTMLFormElement::reset This patch sets up the necessary infrastructure for implementing reset algorithms for form-associated controls.
2022-12-22 19:32:20 -05:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-form-reset-control
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
virtual void reset_algorithm() { }
LibWeb: Implement HTMLFormElement::reset This patch sets up the necessary infrastructure for implementing reset algorithms for form-associated controls.
2022-12-22 19:32:20 -05:00
LibWeb: Implement the form associated element clear algorithm This is a method defined in the WebDriver spec, but requires access to a bunch of private fields in these classes, so this is implemented in the same manner as the reset algorithm.
2024-10-11 10:38:43 -04:00
virtual void clear_algorithm();
LibWeb: Return document URL if formAction attribute is missing or empty This change also ensures that relative URLs are resolved relative to the document's base URL.
2024-09-07 23:17:56 +01:00
String form_action() const;
WebIDL::ExceptionOr<void> set_form_action(String const&);
LibWeb: Unify report_validity for form associated elements This function was implemented in a few classes but is a common element in all form associated elements and the functionality should be there. With these minimal changes we get to implement 4 idl functions for free.
2025-08-29 17:52:55 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-reportvalidity
bool report_validity();
LibWeb: Unify check_validity for form associated elements
2025-08-29 17:56:20 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-checkvalidity
bool check_validity();
LibWeb: Unify will_validate for form associated elements We had the same implementation in quiet a few places. With this change we unify them in a single place
2025-08-29 17:59:15 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-willvalidate
bool will_validate() const;
LibWeb: Implement validation_message for form associated elements It wins us a quick WPT test as well as implement a bunch of IDL methods.
2025-08-29 18:02:59 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-validationmessage
Utf16String validation_message() const;
LibWeb: Implement validity IDL attribute
2025-02-17 20:44:26 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-validity
GC::Ref<ValidityState const> validity() const;
LibWeb: Implement setCustomValidity IDL attribute
2025-02-17 20:50:56 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-cva-setcustomvalidity
void set_custom_validity(String& error);
LibWeb/HTML: Correctly compute whether element is mutable This adapts the implementation of `is_mutable` to align more closely with the spec. Specifically, it is now also taken into account whether the element is enabled.
2025-08-10 00:29:35 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#mutability
virtual bool is_mutable() const { return true; }
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
protected:
FormAssociatedElement() = default;
virtual ~FormAssociatedElement() = default;
virtual void form_associated_element_was_inserted() { }
virtual void form_associated_element_was_removed(DOM::Node*) { }
LibWeb: Implement 'State-preserving atomic move integration' This was recently added to both the HTML and DOM specifications, introducing the new moveBefore DOM API, as well as the new internal 'removing steps'. See: * https://github.com/whatwg/html/commit/432e8fb * https://github.com/whatwg/dom/commit/eaf2ac7
2025-03-08 12:45:26 +13:00
virtual void form_associated_element_was_moved(GC::Ptr<DOM::Node>) { }
LibWeb/HTML: Sanitize email input with multiple attribute This implements the missing part of the value sanitization algorithm for email inputs with the multiple attribute.
2025-07-22 00:58:28 +02:00
virtual void form_associated_element_attribute_changed(FlyString const&, Optional<String> const&, Optional<String> const&, Optional<FlyString> const&) { }
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
void form_node_was_inserted();
void form_node_was_removed();
LibWeb: Implement 'State-preserving atomic move integration' This was recently added to both the HTML and DOM specifications, introducing the new moveBefore DOM API, as well as the new internal 'removing steps'. See: * https://github.com/whatwg/html/commit/432e8fb * https://github.com/whatwg/dom/commit/eaf2ac7
2025-03-08 12:45:26 +13:00
void form_node_was_moved();
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
void form_node_attribute_changed(FlyString const&, Optional<String> const&);
private:
void reset_form_owner();
LibJS+LibWeb: Use GC::Weak instead of AK::WeakPtr for GC-allocated types This makes some common types like JS::Object smaller (by 8 bytes) and yields a minor speed improvement on many benchmarks.
2025-10-16 11:13:54 +02:00
GC::Weak<HTMLFormElement> m_form;
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#parser-inserted-flag
bool m_parser_inserted { false };
LibWeb: Implement setCustomValidity IDL attribute
2025-02-17 20:50:56 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#custom-validity-error-message
String m_custom_validity_error_message;
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
};
LibWeb: Don't move focus when setting input value
2024-09-10 11:28:44 +10:00
enum class SelectionSource {
UI,
DOM,
};
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API FormAssociatedTextControlElement
LibWeb: Ensure EventHandler visits its mouse selection target We hold a raw pointer to the mouse selection target, which is a mixin- style class inherited only by JS::Cell classes. By not visiting this object, we sometime had a dangling reference to it after it had been garbage collected.
2025-02-26 20:40:10 -05:00
: public FormAssociatedElement
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
, public InputEventsTarget {
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
public:
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-relevant-value
LibWeb+WebContent: Port FormAssociatedTextControlElement APIs to UTF-16
2025-07-25 15:04:25 -04:00
virtual Utf16String relevant_value() = 0;
virtual WebIDL::ExceptionOr<void> set_relevant_value(Utf16String const&) = 0;
LibWeb: Implement setRangeText for input and textarea elements This method replaces range of text in its respective element with a new string
2024-08-30 17:22:58 +01:00
virtual void set_dirty_value_flag(bool flag) = 0;
LibWeb: Subclass FormAssociatedElement text selection methods These are only relevant to HTMLInputElement and HTMLTextArea elements.
2024-08-30 17:22:58 +01:00
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-select
WebIDL::ExceptionOr<void> select();
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-selectionstart
LibWeb: Allow keyboard input to alter email inputs Previously, the`HTMLInputElement.selectinStart` and `HTMLInputElement.selectionEnd` IDL setters, and the `setRangeText()` IDL method were used when updating an input's value on keyboard input. These methods can't be used for this purpose, since selection doesn't apply to email type inputs. Therefore, this change introduces internal-use only methods that don't check whether selection applies to the given input.
2024-12-27 17:03:16 +00:00
Optional<WebIDL::UnsignedLong> selection_start_binding() const;
WebIDL::ExceptionOr<void> set_selection_start_binding(Optional<WebIDL::UnsignedLong> const&);
WebIDL::UnsignedLong selection_start() const;
HTML: Put HTMLTextAreaElement selection helpers in FormAssociatedElement This will allow us to more closely follow the spec and share these functions with HTMLInputElement.
2024-07-28 15:55:09 +12:00
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-selectionend
LibWeb: Allow keyboard input to alter email inputs Previously, the`HTMLInputElement.selectinStart` and `HTMLInputElement.selectionEnd` IDL setters, and the `setRangeText()` IDL method were used when updating an input's value on keyboard input. These methods can't be used for this purpose, since selection doesn't apply to email type inputs. Therefore, this change introduces internal-use only methods that don't check whether selection applies to the given input.
2024-12-27 17:03:16 +00:00
Optional<WebIDL::UnsignedLong> selection_end_binding() const;
WebIDL::ExceptionOr<void> set_selection_end_binding(Optional<WebIDL::UnsignedLong> const&);
WebIDL::UnsignedLong selection_end() const;
HTML: Put HTMLTextAreaElement selection helpers in FormAssociatedElement This will allow us to more closely follow the spec and share these functions with HTMLInputElement.
2024-07-28 15:55:09 +12:00
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-selectiondirection
Optional<String> selection_direction() const;
void set_selection_direction(Optional<String> direction);
LibWeb: Follow spec steps to set the selectionDirection attribute value
2024-10-04 12:12:39 +01:00
WebIDL::ExceptionOr<void> set_selection_direction_binding(Optional<String> direction);
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
SelectionDirection selection_direction_state() const { return m_selection_direction; }
LibWeb: Implement setRangeText for input and textarea elements This method replaces range of text in its respective element with a new string
2024-08-30 17:22:58 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-setrangetext
LibWeb+WebContent: Port FormAssociatedTextControlElement APIs to UTF-16
2025-07-25 15:04:25 -04:00
WebIDL::ExceptionOr<void> set_range_text_binding(Utf16String const& replacement);
WebIDL::ExceptionOr<void> set_range_text_binding(Utf16String const& replacement, WebIDL::UnsignedLong start, WebIDL::UnsignedLong end, Bindings::SelectionMode = Bindings::SelectionMode::Preserve);
WebIDL::ExceptionOr<void> set_range_text(Utf16String const& replacement, WebIDL::UnsignedLong start, WebIDL::UnsignedLong end, Bindings::SelectionMode = Bindings::SelectionMode::Preserve);
LibWeb: Implement setRangeText for input and textarea elements This method replaces range of text in its respective element with a new string
2024-08-30 17:22:58 +01:00
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-setselectionrange
LibWeb: Don't move focus when setting input value
2024-09-10 11:28:44 +10:00
void set_the_selection_range(Optional<WebIDL::UnsignedLong> start, Optional<WebIDL::UnsignedLong> end, SelectionDirection direction = SelectionDirection::None, SelectionSource source = SelectionSource::DOM);
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#dom-textarea/input-setselectionrange
WebIDL::ExceptionOr<void> set_selection_range(Optional<WebIDL::UnsignedLong> start, Optional<WebIDL::UnsignedLong> end, Optional<String> direction);
LibWeb: Implement selectionchange event according to spec
2024-10-09 13:50:06 +02:00
// https://w3c.github.io/selection-api/#dfn-has-scheduled-selectionchange-event
bool has_scheduled_selectionchange_event() const { return m_has_scheduled_selectionchange_event; }
void set_scheduled_selectionchange_event(bool value) { m_has_scheduled_selectionchange_event = value; }
LibWeb: Delete EditableTextNodeOwner It's no longer needed after FormAssociatedTextControlElement became responsible for managing input events for text controls.
2024-11-06 16:46:50 +01:00
virtual void did_edit_text_node() = 0;
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
virtual GC::Ptr<DOM::Text> form_associated_element_to_text_node() = 0;
virtual GC::Ptr<DOM::Text const> form_associated_element_to_text_node() const { return const_cast<FormAssociatedTextControlElement&>(*this).form_associated_element_to_text_node(); }
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
LibWeb+WebContent: Port FormAssociatedTextControlElement APIs to UTF-16
2025-07-25 15:04:25 -04:00
virtual void handle_insert(Utf16String const&) override;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
virtual void handle_delete(DeleteDirection) override;
LibWeb: Start integrating the editing API with user keyboard input This reworks EventHandler so text insertion, backspace, delete and return actions are now handled by the Editing API. This was the whole point of the execCommand spec, to provide an implementation of both editing commands and the expected editing behavior on user input. Responsibility of firing the `input` event is moved from EventHandler to the Editing API, which also gets rid of duplicate events whenever dealing with `<input>` or `<textarea>` events. The `beforeinput` event still needs to be fired by `EventHandler` however, since that is never fired by `execCommand()`.
2025-05-09 09:13:32 +02:00
virtual EventResult handle_return_key(FlyString const& ui_input_type) override;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
virtual void select_all() 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
virtual void set_selection_anchor(GC::Ref<DOM::Node>, size_t offset) override;
virtual void set_selection_focus(GC::Ref<DOM::Node>, size_t offset) override;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
virtual void move_cursor_to_start(CollapseSelection) override;
virtual void move_cursor_to_end(CollapseSelection) override;
virtual void increment_cursor_position_offset(CollapseSelection) override;
virtual void decrement_cursor_position_offset(CollapseSelection) override;
virtual void increment_cursor_position_to_next_word(CollapseSelection) override;
virtual void decrement_cursor_position_to_previous_word(CollapseSelection) override;
LibWeb: Implement up/down arrow navigation in textarea
2025-05-10 09:46:09 +02:00
virtual void increment_cursor_position_to_next_line(CollapseSelection) override;
virtual void decrement_cursor_position_to_previous_line(CollapseSelection) override;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +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::Ptr<DOM::Position> cursor_position() const;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 18:55:54 -04:00
protected:
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-relevant-value
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
void relevant_value_was_changed();
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
private:
LibWeb: Ensure EventHandler visits its mouse selection target We hold a raw pointer to the mouse selection target, which is a mixin- style class inherited only by JS::Cell classes. By not visiting this object, we sometime had a dangling reference to it after it had been garbage collected.
2025-02-26 20:40:10 -05:00
virtual GC::Ref<JS::Cell> as_cell() override;
LibWeb: Separate text control input events handling from contenteditable This input event handling change is intended to address the following design issues: - Having `DOM::Position` is unnecessary complexity when `Selection` exists because caret position could be described by the selection object with a collapsed state. Before this change, we had to synchronize those whenever one of them was modified, and there were already bugs caused by that, i.e., caret position was not changed when selection offset was modified from the JS side. - Selection API exposes selection offset within `<textarea>` and `<input>`, which is not supposed to happen. These objects should manage their selection state by themselves and have selection offset even when they are not displayed. - `EventHandler` looks only at `DOM::Text` owned by `DOM::Position` while doing text manipulations. It works fine for `<input>` and `<textarea>`, but `contenteditable` needs to consider all text descendant text nodes; i.e., if the cursor is moved outside of `DOM::Text`, we need to look for an adjacent text node to move the cursor there. With this change, `EventHandler` no longer does direct manipulations on caret position or text content, but instead delegates them to the active `InputEventsTarget`, which could be either `FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or `EditingHostManager` (for `contenteditable`). The `Selection` object is used to manage both selection and caret position for `contenteditable`, and text control elements manage their own selection state that is not exposed by Selection API. This change improves text editing on Discord, as now we don't have to refocus the `contenteditable` element after character input. The problem was that selection manipulations from the JS side were not propagated to `DOM::Position`. I expect this change to make future correctness improvements for `contenteditable` (and `designMode`) easier, as now it's decoupled from `<input>` and `<textarea>` and separated from `EventHandler`, which is quite a busy file.
2024-10-23 21:26:58 +02:00
void collapse_selection_to_offset(size_t);
void selection_was_changed();
LibWeb: Implement input/textarea selection APIs For both types of elements, `.selectionStart`, `.selectionEnd`, `.selectionDirection`, `.setSelectionRange()`, `.select()` and the `select` event are now implemented.
2024-08-22 15:20:24 +02:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-selection
WebIDL::UnsignedLong m_selection_start { 0 };
WebIDL::UnsignedLong m_selection_end { 0 };
SelectionDirection m_selection_direction { SelectionDirection::None };
LibWeb: Implement selectionchange event according to spec
2024-10-09 13:50:06 +02:00
// https://w3c.github.io/selection-api/#dfn-has-scheduled-selectionchange-event
bool m_has_scheduled_selectionchange_event { false };
LibWeb: Add basic support for HTMLInputElement.form HTMLInputElement now inherits from FormAssociatedElement, which will be a common base for the handful of elements that need to track their owner form (and register with it for the form.elements collection.) At the moment, the owner form is assigned during DOM insertion/removal of an HTMLInputElement. I didn't implement any of the legacy behaviors defined by the HTML parsing spec yet.
2021-04-20 11:50:29 +02:00
};
}
Reference in a new issue Copy permalink