From the HTML spec:
Modulo platform conventions, it is suggested that the following
elements should be considered as focusable areas and be sequentially
focusable:
...
- button elements
- select elements
- textarea elements
...
Also add a spec link to the existing HTMLAnchorElement::is_focusable().
Note that this still doesn't allow triggering keyboard-focused buttons,
checkboxes, or radio buttons - we don't seem to run the expected
activation behavior for any of them.
From the HTML spec:
Modulo platform conventions, it is suggested that the following
elements should be considered as focusable areas and be sequentially
focusable:
...
- input elements whose type attribute are not in the Hidden state
...
This commit moves the regular handling of links to the anchor elements'
activation behavior, and implements a few auxiliary algorithms as
defined by the HTML specification.
Note that certain things such as javascript links, fragments and opening
a new tab are still handled directly in EventHandler, but they have been
moved to handle_mouseup so that it behaves closer to how it would if it
was entirely up-to-spec.
Specifically HTMLIFrameElement and HTMLObjectElement. HTMLEmbedElement
will gain it automatically once it's also converted to inherit from
BrowsingContextContainer.
The HTMLObjectElement spec is set up to ignore application/octet-stream
MIME types only. For this to work, we need to implement the MIME type
sniffing algorithm so that all unknown MIME types become mapped to the
application/octet-stream type. Until then, ignore all application/ MIME
types as we won't be able to display them anyways.
We were using the literal string "unknown" as the unknown MIME type,
which caused us to treat the object as a nested browsing context (as
"unknown" does not start with "image/"). Use an Optional instead to
prevent this mishap.
We currently only supported loading image data from an HTMLObjectElement
node. This adds (some) support for non-image data. A big FIXME is to
actually paint that data. We will need to make FrameBox and
NestedBrowsingContextPaintable work with HTMLObjectElement for this
(they currently only work with HTMLIFrameElement).
We will soon have two DOM nodes which contain nested browsing contexts:
HTMLIFrameElement and HTMLObjectElement. Only HTMLIFrameElement should
have its nested context created automatically upon insertion, so move
the invocation of that logic to HTMLIFrameElement.
HTMLObjectElement will need to be both a FormAssociatedElement and a
BrowsingContextContainer. Currently, both of these classes inherit from
HTMLElement. This can work in C++, but is generally frowned upon, and
doesn't play particularly well with the rest of LibWeb.
Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement
from FormAssociatedElement's hierarchy. This means that objects such as
HTMLObjectElement individually inherit from FormAssociatedElement and
HTMLElement now.
Some caveats are:
* FormAssociatedElement still needs to know when the HTMLElement is
inserted into and removed from the DOM. This hook is automatically
injected via a macro now, while still allowing classes like
HTMLInputElement to also know when the element is inserted.
* Casting from a DOM::Element to a FormAssociatedElement is now a
sideways cast, rather than directly following an inheritance chain.
This means static_cast cannot be used here; but we can safely use
dynamic_cast since the only 2 instances of this already use RTTI to
verify the cast.
This is another event upon which the task to determine an object's
respresentation must be queued:
* one of the element's ancestor object elements changes to or from
showing its fallback content
For example, on Acid2, the image for the eyes is nested below an object
that is designed to fail to load. This ensures the eyes will render as
the fallback of the failed parent object.
There are a long list of conditions under which the HTMLObjectElement is
to queue an element task to load / determine an object's representation.
This handles the case where the data attribute has changed.
Much of the spec for determining the object's representation is not
implemented here. Namely, anything to do with XML documents or browser
plugins are left as FIXMEs.
This replaces the usage of `rounded_int_rect`, whose name did not
accurately reflect the rounding operation happening. For example, the
position of the rect was not rounded but floored, and the size was
pulled through `roundf` before casting to `int` which could result in
inadvertent flooring if the resulting floating point could not exactly
represent the rounded value.
We should not set the 'value' attribute when an input element's value is
changed (by the user or programmatically). Instead, we should track the
value internally and mark it with a dirty flag when it is changed.
The HTML Specification is quite tricky in this case.
Usually "have a particular element in <x> scope" mentions
"consisting of the following element types:", but in this case it's
"consisting of all element types except the following:"
Thanks to @AtkinsSJ for spotting this difference
Instead of choking on the VERIFY(document), let's just return null if
there's no active document for now. This is incorrect, but sidesteps
a frequent crash that happens on content with iframes.
I've left a FIXME about removing the hack once it's no longer needed.
