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)
Previously the entire slider track was colored.
Now only the lower part of the slider track (left side of the thumb) is
colored.
Chrome and Firefox do the same.
(cherry picked from commit 7766909415312b971252f8c7750b0a1873fd5ba0)
The style of input and textarea elements is now invalidated when focus
is changed to a new element. This ensures any `:focus` selectors are
applied correctly.
(cherry picked from commit 572324d47b99bcfbc5db5ff6aef0d6c4eb15ce4c)
...and shadow tree with TextNode for "value" attribute is created.
This means InlineFormattingContext is used, and button's text now
respects CSS text-decoration properties and unicode-ranges.
(cherry picked from commit 8feaecd5c8d02a2fdb989a9a9671e008d1c3a7de)
This fixes https://html5test.com/ as previously an exception was being
thrown after trying to access this attribute which would then result in
a popup about the test failing (and none of the test results being
shown).
(cherry picked from commit e0bbbc729b6aad04ceff5f67c3e2868b65970047,
manually amended with the output of `git clang-format master`)
And let the old shadow_root(), which was only supposed to be used by
bindings, be called shadow_root_for_bindings() instead.
This makes it much easier to read DOM code, and we don't have to worry
about when to use shadow_root_internal() or why.
(cherry picked from commit f4bdf562127c12a7af18029777a88d4260af82d3)
This was resulting in a whole lot of rebuilding whenever a new IDL
interface was added.
Instead, just directly include the prototype in every C++ file which
needs it. While we only really need a forward declaration in each cpp
file; including the full prototype header (which itself only includes
LibJS/Object.h, which is already transitively brought in by
PlatformObject) - it seems like a small price to pay compared to what
feels like a full rebuild of LibWeb whenever a new IDL file is added.
Given all of these includes are only needed for the ::initialize
method, there is probably a smart way of avoiding this problem
altogether. I've considered both using some macro trickery or generating
these functions somehow instead.
Rather than each element which supports dimension attributes needing to
implement parsing the attributes and setting the appropriate style, we
can generalize this functionality. This will also make each element more
closely resemble the spec text, as we will be effectively declaring, for
example, "The img element supports dimension attributes" in code.
This is often used on login forms, for example, to toggle the visibility
of a password. The site will change the <input> element's type to "text"
to allow the password to show.
This commit introduces a WEB_SET_PROTOTYPE_FOR_INTERFACE macro that
caches the interface name in a local static FlyString. This means that
we only pay for FlyString-from-literal lookup once per browser lifetime
instead of every time the interface is instantiated.
