It makes no sense to require passing a global object and doing a stack
space check in some cases where running out of stack is highly unlikely,
we can't recover from errors, and currently ignore the result anyway.
This is most commonly in constructors and when setting things up, rather
than regular function calls.
Right now the only functionality supported is getting/setting via JS
and resetting when browsing cross origin.
The HTML Specification (7.11 Browsing the web) also specifies how the
name should be restored from history entries, but we don't have those
yet.
This adds (or at least stubs-out) the following:
- display-mode
- dynamic-range
- environment-blending
- forced-colors
- horizontal-viewport-segments
- vertical-viewport-segments
- inverted-colors
- nav-controls
- prefers-contrast
- prefers-reduced-data
- prefers-reduced-motion
- prefers-reduced-transparency
- scripting
- video-color-gamut
- video-dynamic-range
The `@media (inverted-colors)` CSS that the spec requires we add to the
UA style sheet does not actually do anything for us yet since we don't
support `filter`, but it seemed sensible to include it now to avoid
forgetting later. :^)
Use the stub implementation of HTMLOptionsCollection to expose the
`option` children of `select` elements.
This fixes a JS error on openstreetmap.org, which occured when JQuery
code tried to access `options.length`:
https://github.com/jquery/jquery/blob/main/src/attributes/val.js#L121
This is a subtype of `DOM::HTMLCollection` that only holds
`HTMLOptionElement`s. In this stub implementation only `item`,
`namedItem` and `length`, inherited from HTMLCollection, are exposed.
This is good enough for applications that only read the collection.
This doesn't have any performance benefit yet as we still do string
comparisons everytime, but it should improve once type_state() has a
better implementation.
This commit is messy due to the Paintable and Layout classes being
tangled together.
The RadioButton, CheckBox and ButtonBox classes are now subclasses of
FormAssociatedLabelableNode. This subclass separates these layout nodes
from LabelableNode, which is also the superclass of non-form associated
labelable nodes (Progress).
ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer
call events on DOM nodes directly from their mouse event handlers;
instead, all the functionality is now directly in EventHandler, which
dispatches the related events. handle_mousedown and related methods
return a bool indicating whether the event handling should proceed.
Paintable classes can now return an alternative DOM::Node which should
be the target of the mouse event. Labels use this to indicate that the
labeled control should be the target of the mouse events.
HTMLInputElement put its activation behavior on run_activation_behavior,
which wasn't actually called anywhere and had to be manually called by
other places. We now use activation_behavior which is used by
EventDispatcher.
This commit also brings HTMLInputElement closer to spec by removing the
did_foo functions that did ad-hoc event dispatching and unifies the
behavior under run_input_activation_behavior.
Previously, we were creating a user-agent shadow tree when constructing
a layout tree. This meant that we did DOM manipulation (and consequently
style invalidation) during layout tree construction, which made things
very hard to reason about in Layout::TreeBuilder.
Simply everything by simply creating the UA shadow tree when the input
element inserted into a parent node instead.
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
Not sure why these are doubles in the IDL definition, both the IDL in
the spec and the implementation in the CanvasRenderingContext2D class
use integers.
Also add support for HTMLCanvasElement for the image parameter, leading
to replacing HTMLImageElement with the CanvasImageSource Variant type.
Also stub out the 'check the usability of the image argument' and 'is
not origin-clean' operations, while taking into consideration that these
can throw (and require DOM::ExceptionOr).
