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.
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.
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.
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.
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.
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.
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.
For both types of elements, `.selectionStart`, `.selectionEnd`,
`.selectionDirection`, `.setSelectionRange()`, `.select()` and the
`select` event are now implemented.
Previously, only DOM nodes with `is_editable()` allowed selection via
the mouse. This had the unwanted consequence, that read-only
input/textarea elements did not allow selection.
Now, `EventHandler::handle_mousedown()` asks the node's non-shadow
parent element over the new virtual method `is_child_node_selectable()`,
if selection of the node is allowed.
This method is overridden for `HTMLButtonElement` and
`HTMLInputElement`, to disallow selection of buttons and placeholders.
Fixes#579
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
