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

253 lines
15 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>
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 <AK/WeakPtr.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: 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
} \
\
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: Include namespace parameter in `associated_attribute_changed()`
2024-12-12 19:48:32 +00:00
form_associated_element_attribute_changed(name, 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: 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
class 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
virtual bool is_auto_capitalize_inheriting() const { return false; }
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: 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: 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 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
virtual String value() const { return String {}; }
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: 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: 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: Include namespace parameter in `associated_attribute_changed()`
2024-12-12 19:48:32 +00:00
virtual void form_associated_element_attribute_changed(FlyString 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();
void form_node_attribute_changed(FlyString const&, Optional<String> const&);
private:
void reset_form_owner();
WeakPtr<HTMLFormElement> m_form;
// 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: 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
class FormAssociatedTextControlElement
: 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
virtual String relevant_value() = 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 WebIDL::ExceptionOr<void> set_relevant_value(String const&) = 0;
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: 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
WebIDL::ExceptionOr<void> set_range_text_binding(String const& replacement);
WebIDL::ExceptionOr<void> set_range_text_binding(String 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
WebIDL::ExceptionOr<void> set_range_text(String const& replacement, WebIDL::UnsignedLong start, WebIDL::UnsignedLong end, Bindings::SelectionMode = Bindings::SelectionMode::Preserve);
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: Refactor "editable" and "editing host" concepts The DOM spec defines what it means for an element to be an "editing host", and the Editing spec does the same for the "editable" concept. Replace our `Node::is_editable()` implementation with these spec-compliant algorithms. An editing host is an element that has the properties to make its contents effectively editable. Editable elements are descendants of an editing host. Concepts like the inheritable contenteditable attribute are propagated through the editable algorithm.
2024-12-06 11:41:20 +01:00
bool is_mutable() const { return m_is_mutable; }
void set_is_mutable(bool is_mutable) { m_is_mutable = is_mutable; }
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
virtual void handle_insert(String const&) override;
virtual void handle_delete(DeleteDirection) override;
LibWeb: Do not insert "return" key presses into input element values When the return key is pressed, we try to handle it as a commit action for input elements. However, we would then go on to actually insert the return key's code point (U+000D) into the input element. This would be sanitized out, but would leave the input element in a state where it thinks it has text to commit. This would result in a change event being fired when the return key is pressed multiple times in a row. We were also firing the beforeinput/input events twice for all return key presses. To fix this, this patch changes the input event target to signify if it actually handled the return key. If not (i.e. for textarea elements), only then do we insert the code point. We also must not fall through to the generic key handler, to avoid the repeated input events.
2025-03-21 11:35:42 -04:00
virtual EventResult handle_return_key() 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;
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: Refactor "editable" and "editing host" concepts The DOM spec defines what it means for an element to be an "editing host", and the Editing spec does the same for the "editable" concept. Replace our `Node::is_editable()` implementation with these spec-compliant algorithms. An editing host is an element that has the properties to make its contents effectively editable. Editable elements are descendants of an editing host. Concepts like the inheritable contenteditable attribute are propagated through the editable algorithm.
2024-12-06 11:41:20 +01:00
// https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#mutability
bool m_is_mutable { true };
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