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).
Services expect cookies to be submitted with forms, especially login
screens.
Allows us to sign in to GitHub (including two factor authentication)
and start using it!
This allows us to submit forms from <button> elements and not just
<input type="submit">
This allows Discord to progress past the username registration :^)
This makes it available for all form associated elements and not just
select and input elements. It also makes it more spec compliant,
especially around the form attribute.
The main thing missing is re-associating form elements with a form
attribute when the form attribute changes or an element with an ID
is inserted/removed or has its ID changed.
A top level browsing context is a browsing context with no parent
browsing context.
However, we considered a top level browsing context to be a browsing
context with no associated browsing context container.
