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.
...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.
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).
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.
We had previous implemented some plumbing for file input elements in
commit 636602a54e.
This implements the return path for chromes to inform WebContent of the
file(s) the user selected. This patch includes a dummy implementation
for headless-browser to enable testing.
This creates a button to prompt users to select a file, and a label to
show information about the selected file(s). Clicking either shadow
element will activate the input element.
We currently copy-paste a series of if statements to selectively update
the shadow tree elements for some <input> types. This will soon become
longer as more shadow trees are implemented for other types.
This patch just moves those checks to a single location to make adding
more shadow trees easier.
When an <input type=image> button is clicked, we now send the (x,y)
coordinates of the click event (relative to the image) along with the
form submission data.
Regarding the text test, we can currently only test this feature with
dialogs. The headless-browser test infrastructure cannot yet handle the
resulting navigation that would occur if we were to test with normal
form submission.
This implements enough to represent <input type=image> with its loaded
source image (or fallback to its alt text, if applicable). This does not
implement acquring coordinates from user-activated click events on the
image.
