This API will always succeed in creating a String representing the
provided number in base-10.
(cherry picked from commit dd419b5a8df3b9a32478c4a8f0ea9f70334214cd;
amended to update the rest of the system. No conflicts though!)
Everyone was already using this API as if it were infallible anyway.
(cherry picked from commit 600cb5ccbaba019954f17c7d317ba6fe54a24117;
amended to fix another conflict in StyleComputer.cpp due to serenity
still not having the third commit of LadybirdBrowser/ladybird#1278)
It already returns an empty Optional for failures, so there's no need to
wrap it in an ErrorOr as well.
(cherry picked from commit 5c20bc2afc23b04ccd8037d414592e4ee841a053;
amended to fix conflict in StyleComputer.cpp due to serenity not having
the third commit of LadybirdBrowser/ladybird#1278)
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.
(cherry picked from commit 516f5f70081526ddef2d4a88fc5a1ae916e12fab)
This fixes WPT html/semantics/forms/resetting-a-form/reset-form.html.
I added a test based on the WPT test, but simpler.
(cherry picked from commit caf74e7ed69c6f64fc2f770d03fe61bc60cdc08b)
Before this change, we transferred the input element's line-height to
both the editable text *and* the placeholder. This caused some strange
doubling of the effective line-height when the editable text was empty,
pushing down the placeholder.
(cherry picked from commit 13ba491924c4fc3831d5a8986673d832a721f545;
amended some slighly different horizontal sizes in the expectations
file. Maybe due to serenity not using harfbuzz for shaping, or due
to not have another earlier change yet. If it's the latter, this will
fix itself when that's brought in.)
There was no need to use FlyString for error messages, and it just
caused a bunch of churn since these strings typically only existed
during the lifetime of the error.
(cherry picked from commit 175f3febb8037a440d4ead7347d3266ee3d345e1;
minorly amended to fix conflict in WebSocket.cpp due to serenity
not having the adapter class removal in LadybirdBrowser/ladybird#1671)
These don't have to worry about the input not being valid UTF-8 and
so can be infallible (and can even return self if no changes needed.)
We use this instead of Infra::to_ascii_{upper,lower}_case in LibWeb.
(cherry picked from commit 073bcfd3866852a4c4bcca2bd131bd65ae53541f)
This is because toggling the checkbox is committing the value.
(cherry picked from commit 3856dd946b94b61be2ddac80c8cf60278fcc56ab;
amended to add spaces to expected output due to serenity not yet
having LadybirdBrowser/ladybird#1603, and to add a trailing newline
to the test input file)
This change ensures that the value sanitization algorithm is run and
the text cursor is set to the correct position when the type attribute
of an input is changed.
(cherry picked from commit 1b74104c17726018788034f2ad66201889ce6225)
Previously, the value sanitization algorithm would not trim whitespace
for inputs of type URL or email, if they didn't also contain any
newlines.
(cherry picked from commit c4b82318f41ecc0a3e24fe5c8ca0a3f02816c3b1)
Otherwise, it looks a bit awkward where the cursor position does not
update while the selection is elsewhere.
Note that this requires passing along the raw selection positions from
`set the selection range` to the elements. Otherwise, consider what will
happen if we set the selection start and end to the same value. By going
through the API accessor, we hit the case where the start and end are
the same value, and return the document cursor position. This would mean
the cursor position would not be updated.
The test changes here more closely match what Firefox produces now. It
is not a 100% match; the `select event fired` test case isn't right. The
problem is the event fires for the input element, but we most recently
focused the textarea element. Thus, when we retrieve the selection from
the input element, we return the document's cursor position, which is
actually in the textarea element. The fix will ultimately be to fully
implement the following:
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#concept-textarea/input-cursor
That is, each input / textarea element should separately track its own
text cursor position.
(cherry picked from commit fd289deb44e0fc26f54a133c637c136bf0716cd5)
Calling `.setSelectionRange()` or `.select()` now updates the document
selection as well, visualizing the text selection.
(cherry picked from commit 732e3fa82f216a6f4114eb0e6bb89e167e95ab42)
For both types of elements, `.selectionStart`, `.selectionEnd`,
`.selectionDirection`, `.setSelectionRange()`, `.select()` and the
`select` event are now implemented.
(cherry picked from commit 814ca3267ed73d7ad8492ef69ff87f95240cf922)
I believe this is slightly less confusing, since what the function does
is trigger a full layout tree *rebuild*, not just a relayout.
(cherry picked from commit aa8f17aea4d1aa1950a66969fc8b5c431fbc1b7c)
Previously, we were searching for other radio buttons from the document
root, rather than the element root.
(cherry picked from commit 67981af276cf55d69d51a872ec83e5b59d793b6c)
When the user clicks on a text node, the event handler sets the cursor
position to the location that was clicked. But it would then be set back
to 0 in the DOM node's focus handler. Leave the cursor alone, unless the
the DOM node was never set as the cursor position node (which will occur
when the user clicks on the DOM node, but outside the shadow text node).
In that case, move the cursor to the end of the text node.
The end result here is that the cursor is placed where the user clicked,
or set to the end of node if the user clicked outside of the shadow text
node.
(cherry picked from commit fc37c4ad40beba249a7ea5452f11014d43da68f6)
Per css-ui-4, setting `appearance: none` is supposed to suppress the
creation of a native-looking widget for stuff like checkboxes, radio
buttons, etc.
This patch implements this behavior by simply falling back to creating
a layout node based on the CSS `display` property in such cases.
This fixes an issue on the hey.com imbox page where we were rendering
checkboxes on top of sender profile photos.
(cherry picked from commit 58c523ae46af90ab17d6b98966d97fa776ae2bf4)
This factory forced callers to make a list of GC-allocated FileAPI::File
objects. This isn't safe - this opens a window for these files to be
garbage collected before the FileList object stores / visits the list.
Instead, only allow creating an empty FileList and incrementally adding
files to that list.
(cherry picked from commit 8b4d28b5fd7857e3ee47a8d50aa9c01920dcfb4b)
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
(cherry picked from commit ddbfac38b0074819470766846fca08fd78630eb0;
minorly amended for conflicts in AK/Debug.h.in and
Meta/CMake/all_the_debug_macros.cmake due to us having more debug
macros. Also, downstream got alphabetical order for
STYLE_INVALIDATION_DEBUG wrong.)
Navigables are re-used for navigations within the same tab. Its current
ownership of the cursor position is a bit ad-hoc, so nothing in the spec
indicates when to reset the cursor, nor do we manually do so. So when a
cursor update happens on one page, that cursor is retained on the next
page.
Instead, let's have the document own the cursor. Each navigation results
in a new document, thus we don't need to worry about resetting cursors.
This also makes many of the callsites feel nicer. We were previously
often going from the node, to the document, to the navigable, to the
cursor. This patch removes the navigable hop.
(cherry picked from commit faebbbc281d1267062770b02fc6d962d92a3bd62)
Now that the implementation is in FormAssociatedElement, the
implementation in HTMLInputElement is effectively just a passthrough,
with some minor differences to handle small behavioural quirks between
the two (such as the difference in nullability of types).
(cherry picked from commit 9f24176cac862c42c9cf4d3ac0e757397a5f6ae1)
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
(cherry picked from commit 6a74b0164423d63904cf5a5b594772b595f57600;
very minorly amended to fix conflict in GenerateCSSKeyword.cpp caused
by #22870, and in libweb_generators.cmake due to us not having
https://github.com/LadybirdBrowser/ladybird/pull/741)
For the SVG <use> element, we want to support loading HTML documents
that have a SVG element inside of it pointed to by the URL fragment.
In this situation we would need to fetch and parse the entire document
in SharedImageRequest (so that we can still cache the SVGs). Rename
SharedImageRequest to SharedResourceRequest to make the class a little
more generic for future usecases.
(cherry picked from commit a342370dfb4f1eeabc7dcb8fbe6f8e4eb6f6b1f4)
This matches the behavior of other browsers. Previously, a click event
was used, so the value was only updated when the mouse was released.
(cherry picked from commit b4b947c60797328d930c8d3de466b8ef292d0ed4)
An input event is now fired when the step up or step down button of an
input element of type number is clicked.
This ensures that any associated <output> element is updated when these
buttons are clicked.
(cherry picked from commit 2a980816e756d727261d53450b4b3f48069d5d50)
Input elements without a defined user-interaction behavior need to fire
an input event when the user changes the element's value in some way.
This change moves the code to do this into its own function and adds
some spec text to explain what is being done.
(cherry picked from commit a3d12e569c88d0dae530657e5bddc18699fb9c9b)
Previously the input element was displayed with value 0, when no value
was set in the HTML. Now it uses `value_sanitization_algorithm()`, which
will calculate the default value.
In `value_sanitization_algorithm()` there was a logical mistake/typo.
The comment from the spec says "unless the maximum is less than the
minimum".
The added layout test would fail without the code changes.
Fixes#520
(cherry picked from commit 191531b7b18d2edf97dc7bf88a9c19903eeae2d5)
Previously, setting CSS `line-height: 0` on an `input` element would
result in no text being displayed.
Other browsers handle this by setting the minimum height to the
"normal" value for single line inputs.
(cherry picked from commit 629068c2a7eb02db37ffb4fe8d536306ee71e156)
