The DOM spec gets overridden by both the SVG2 and MathML core specs in
that unknown elements should not inherit DOM::Element, but
SVG::SVGElement and MathML::MathMLElement respectively.
This is a mixin in the IDL, so let's treat it as a mixin in our code and
let both SVGElement and MathMLElement reuse the implementations that we
wrote for HTMLElement.
This change helps to ensure issue authors include the details needed to
reproduce problems — including repro steps, expected behavior, a reduced
test case, and logs/backtrace.
Previously, attempting to parse a floating point number with an integer
part larger than `(2 ^ 31) - 1` would cause the browser to crash. We now
avoid this by converting the integer part of the number to a `double`
rather than an `i32`.
This change makes the Meta/import-wpt-test.py script handle URLs such as
https://wpt.live//WebCryptoAPI/generateKey/../util/helpers.js and paths
containing, e.g., wpt-import/WebCryptoAPI/generateKey/../util/helpers.js
(that is, URLs and paths with “..” parent-directory references in them).
Otherwise, without this change, when the import-wpt-test.py script tries
a URL like https://wpt.live//WebCryptoAPI/generateKey/../util/helpers.js
which contains a “..” parent-directory reference, the script fails with
a “urllib.error.HTTPError: HTTP Error 404: Not Found” error message.
This avoids needing to creating root handles for each heap-allocated
object captured in the animation callback. An upcoming commit would add
several of these.
Fixes wpt/png/exif-chunk.html.
At some point there should probably be some mechanism to handle this
outside of the individual decoder plugins. The TIFF decoder seems to
have its own version of this, and as far as I can tell, the JPEG decoder
doesn't handle this at all, even though that's probably the most common
use case for Exif orientations. :^)
This change imports the WPT accname/name/comp_embedded_control.html
test, along with related resources files it depends on.
Note that in the wai-aria/scripts/aria-utils.js file, this changes the
get_computed_label call to use our window.internals.getComputedLabel.
This change implements the “C: Embedded Control” step at
https://w3c.github.io/accname/#step2C in the “Accessible Name and
Description Computation” spec — to compute the accessible names for
labeled form controls.
Similar to commit a9c858fc78, this patch
implements the WebDriver spec concept of shadow references grouped
according to their browsing context groups.
We currently spin the event loop to wait for the specified element to
become available. As we've seen with other endpoints, this can result
in dead locks if another web component also spins the event loop.
This patch makes the locator implementations asynchronous.
We paint grid item nodes as a stacking context when they have no
`z-index` style set. However, a grid item could already have a stacking
context established - for example, when the `filter` style is applied.
This causes these nodes to be drawn twice.
Skip painting grid item nodes if a stacking context is already present.
This seems to have vanished from the spec, but in any case, we still
need it. Without this change we erroneously thought that calculations
that match <percentage> did not match <number-percentage>.
This will allow us to remove the use of SafeFunction in it's
implementation. This requires a fair amount of plumbing to wire up the
GC heap to the appropriate places in order to create the timers.
This input event handling change is intended to address the following
design issues:
- Having `DOM::Position` is unnecessary complexity when `Selection`
exists because caret position could be described by the selection
object with a collapsed state. Before this change, we had to
synchronize those whenever one of them was modified, and there were
already bugs caused by that, i.e., caret position was not changed when
selection offset was modified from the JS side.
- Selection API exposes selection offset within `<textarea>` and
`<input>`, which is not supposed to happen. These objects should
manage their selection state by themselves and have selection offset
even when they are not displayed.
- `EventHandler` looks only at `DOM::Text` owned by `DOM::Position`
while doing text manipulations. It works fine for `<input>` and
`<textarea>`, but `contenteditable` needs to consider all text
descendant text nodes; i.e., if the cursor is moved outside of
`DOM::Text`, we need to look for an adjacent text node to move the
cursor there.
With this change, `EventHandler` no longer does direct manipulations on
caret position or text content, but instead delegates them to the active
`InputEventsTarget`, which could be either
`FormAssociatedTextControlElement` (for `<input>` and `<textarea>`) or
`EditingHostManager` (for `contenteditable`). The `Selection` object is
used to manage both selection and caret position for `contenteditable`,
and text control elements manage their own selection state that is not
exposed by Selection API.
This change improves text editing on Discord, as now we don't have to
refocus the `contenteditable` element after character input. The problem
was that selection manipulations from the JS side were not propagated
to `DOM::Position`.
I expect this change to make future correctness improvements for
`contenteditable` (and `designMode`) easier, as now it's decoupled from
`<input>` and `<textarea>` and separated from `EventHandler`, which is
quite a busy file.
Makes this method to not fail if updating of start offset (which happens
before update of the end offset) already moved end offset to the end of
string on the following step:
> 1. If range’s root is not equal to node’s root, or if bp is after the
range’s end, set range’s end to bp.
