Commit graph

15 commits

Author SHA1 Message Date
Shannon Booth
31a3bc3681 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:

 * 432e8fb
 * eaf2ac7
2025-04-26 08:45:37 -06:00
Timothy Flynn
5f0f97b3cc 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-22 17:27:45 +01:00
Timothy Flynn
d5be18617e 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-27 09:53:13 +00:00
sideshowbarker
7c34746571 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-26 04:13:31 +00:00
Psychpsyo
a8004a77bb LibWeb: Implement setCustomValidity IDL attribute 2025-02-18 10:17:06 -07:00
Psychpsyo
83c4e22247 LibWeb: Implement validity IDL attribute 2025-02-18 06:37:11 +00:00
Andrew Kaster
adfb371e4f LibWeb: Reference multipage spec for form element constraints 2025-02-05 17:35:10 -07:00
Psychpsyo
bad7324307 LibWeb: Implement CSS validity pseudo-classes 2025-02-05 12:38:55 +00:00
Andreas Kling
7269fc3e52 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 21:38:31 +01:00
Tim Ledbetter
db24440403 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-30 11:04:16 +01:00
Tim Ledbetter
40cb36607c LibWeb: Include namespace parameter in associated_attribute_changed() 2024-12-14 12:11:28 -08:00
Jelle Raaijmakers
1c55153d43 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-10 14:54:19 +01:00
Shannon Booth
f87041bf3a 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 14:49:20 +01:00
Timothy Flynn
d4f8b598cb 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 15:39:02 +01:00
Timothy Flynn
93712b24bf Everywhere: Hoist the Libraries folder to the top-level 2024-11-10 12:50:45 +01:00
Renamed from Userland/Libraries/LibWeb/HTML/FormAssociatedElement.h (Browse further)