Elements with transforms were tested on their pre-transformed
positions, causing incorrect hits.
Copy the position transformation done in `StackingContext::hit_test`
to ensure that hit tests are done on the _actual_ position.
The repository being in static storage is a bit of a hodgepodge, but in
line with how our current storage partitioning is done. We should
eventually move this, along with other across browsing context APIs to a
proper location at a later stage. But for now, this makes progress on
the meat of the BroadcastChannel API.
In the case where we had a preferred aspect ratio and a natural height
but no natural width, we'd get into ping-ponging infinite recursion by
trying to find the width to resolve the height to resolve the width to
resolve the height...
This change adds support for computing accessible names for SVG
elements, per the https://w3c.github.io/svg-aam/#mapping_additional_nd
spec requirements. Otherwise, without this change, accessible names for
SVG elements don’t get exposed as expected.
Also removing a FIXME about not covering all of the event names as it is
not exactly clear when such a FIXME would be addressed, especially as
these come from multiple specifications.
Now, along with the mouse events we also dispatch pointerup, pointerdown
and pointermove.
With this change shape painting works on https://excalidraw.com/
Previously, the list was copied when constructing the FormData object,
then the original list was passed to the event, meaning any changes to
the list that happened within the event would not be reflected outside
of it.
For example, in the following HTML:
```html
<label>
<input type="radio" name="fruit" value="apple" id="radio1">
<span class="box"></span>
</label>
```
When any descendant of a <label> element is clicked, a "click" event
must be dispatched on the <input> element nested within the <label>, in
addition to the "click" event dispatched on the clicked descendant.
Previously, this behavior was implemented only for text node descendants
by "overriding" the mouse event target using `mouse_event_target()` in
the TextPaintable. This approach was incorrect because it was limited to
text nodes, whereas the behavior should apply to any box. Moreover, the
"click" event for the input control must be dispatched *in addition* to
the event on the clicked element, rather than redirecting it.
The clientX and clientY values are, as per the spec, the offset from
the viewport.
This makes them actually be that and also fixes up the calculations
for offsetX, offsetY, pageX and pageY.
I assume all of these got messed up in some sort of refactor in the
past.
The spec comment from the now-removed
compute_mouse_event_client_offset() function sadly has no convenient
place to be anymore so, for now, it is just gone as well.
Personally, I think it'd make sense to refactor a lot of this file so
that not every mouse event repeats a large chunk of (almost) identical
code. That way there'd be a nice place to put the comment without
repeating it all over the file.
But that is out of the scope of this PR.
Also: I know, offsetX and Y are not fully fixed yet, they still
don't ignore the element's CSS transforms but I am working on that
in a new PR.
This change fixes unhoverable toolbar on https://excalidraw.com/
The problem was that React.js uses setProperty() to add style properties
specified in the "style" attribute in the virtual DOM, and we were
failing to add the CSS variable used to set the "pointer-events" value
to "all".
In line with the ShadowRealm proposal changes in the WebIDL spec:
webidl#1437 and supporting changes in HTML spec.
This is required for ShadowRealms as they have no relevant settings
object on the shadow realm, so fixes a crash in the QueueingStrategy
test in this commit.
These interfaces are exposed on *, meaning it should work for workers
and our newly added shadow realm global object by being stored on the
universal global scope mixin.
This is required by mini Cloudflare invisible challenges, as it will
only run if the readyState is not "loading". If it is "loading", then
it waits for readystatechange to check that it's not "loading" anymore.
Initial about:blank iframes do not go through the full navigation and
thus don't go through HTMLParser::the_end, which sets the ready state
to something other than "loading". Therefore, the challenge would never
run, as readyState would never change.
Seen on https://discord.com/login
CDATASection inherits from Text, and so it was incorrect for them to
claim not to be Text nodes.
This fixes at least two WPT subtests. :^)
It also exposed a bug in the DOM Parsing and Serialization spec,
where we're not told how to serialize CDATASection nodes.
Spec bug: https://github.com/w3c/DOM-Parsing/issues/38
Instead of checking the header in ZlibDecompressor::create(), we now
check it in read_some() when it is called for the first time. This
resolves a FIXME in the new DecompressionStream implementation.
This change ensures that:
- if an element for which an accessible name otherwise wouldn’t be
computed is referenced in an aria-labelledby value, the accessible
name for the element will be computed as expected.
- if an element has both an aria-label value and also an
aria-labelledby value, the text from the aria-label value gets
included in the computation of the element’s accessible name.
Otherwise, without this change, some elements with aria-labelledby
values will unexpectedly end up without accessible names, and some
elements with aria-label values will unexpectedly not have that
aria-label value included in the element’s accessible name.
The MessagePort one in particular is required by Cloudflare Turnstile,
as the method it takes to run JS in a worker is to `eval` the contents
of `MessageEvent.data`. However, it will only do this if
`MessageEvent.isTrusted` is true, `MessageEvent.origin` is the empty
string and `MessageEvent.source` is `null`.
The Window version is a quick fix whilst in the vicinity, as its
MessageEvent should also be trusted.
