The `cursor` property accepts a list of possible cursors, which behave
as a fallback: We use whichever cursor is the first available one. This
is a little complicated because initially, any remote images have not
loaded, so we need to use the fallback standard cursor, and then switch
to another when it loads.
So, ComputedValues stores a Vector of cursors, and then in EventHandler
we scan down that list until we find a cursor that's ready for use.
The spec defines cursors as being `<url>`, but allows for `<image>`
instead. That includes functions like `linear-gradient()`.
This commit implements image cursors in the Qt UI, but not AppKit.
We hold a raw pointer to the mouse selection target, which is a mixin-
style class inherited only by JS::Cell classes. By not visiting this
object, we sometime had a dangling reference to it after it had been
garbage collected.
Our existing coalescing mechanism for input events didn't prevent
multiple mousemove/mousewheel events from being processed between paint
cycles. Since handling these events can trigger style & layout updates
solely for hit-testing purposes, we might end up doing work that won't
be observable by a user and could be avoided by shceduling input events
processing to happen right before painting the next frame.
Previously, if the user made a find-in-page query, then cleared the
selection made by that query, subsequent queries would inadvertently
advance to the next match instead of reselecting the first match.
Some tests take longer than others, and so may want to set a custom
timeout so that they pass, without increasing the timeout for all other
tests. For example, this is done in WPT.
Add an `internals.setTestTimeout(milliseconds)` method that overrides
the test runner's default timeout for the currently-run test.
That is what the spec calls it, at least.
In code, this manifests as making the offset very aware
of the element's transform, because the click position comes
relative to the viewport, not to the transformed element.
There are essentially 3 URL parsing AOs defined by the spec:
1. Parse a URL
2. Encoding parse a URL
3. Encoding parse a URL and serialize the result
Further, these are replicated between the Document and the ESO.
This patch defines these methods in accordance with the spec and updates
existing users to invoke the correct method. In places where the correct
method is ambiguous, we use the encoding parser to preserve existing ad-
hoc behavior.
The DOM spec defines what it means for an element to be an "editing
host", and the Editing spec does the same for the "editable" concept.
Replace our `Node::is_editable()` implementation with these
spec-compliant algorithms.
An editing host is an element that has the properties to make its
contents effectively editable. Editable elements are descendants of an
editing host. Concepts like the inheritable contenteditable attribute
are propagated through the editable algorithm.
Before, on a mouse-move event, if the hovered html element did not have
a tooltip or it was not a link, `page_did_leave_tooltip_area()` and
`page_did_unhover_link()` virtual functions would get called.
Now, the page remembers if it is in a tooltip area or hovering a link
and only informs of leaving or unhovering only if it was.
Before, on *every* mouse-move event, `page_did_request_cursor_change()`
virtual function would get called, requesting to change cursor to the
event's mouse position's cursor.
Now, the page keeps track of the last cursor change that was requested
("page's current cursor") and only requests cursor change again if and
only if the current cursor is not already the one that is required.
Now, along with the mouse events we also dispatch pointerup, pointerdown
and pointermove.
With this change shape painting works on https://excalidraw.com/
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.
I believe this is an error in the UI Events spec, and it should be
updated to match the HTML spec (which uses WindowProxy everywhere).
This fixes a bunch of issues already covered by existing WPT tests.
Spec bug: https://github.com/w3c/uievents/issues/388
Note that WebKit has been using WindowProxy instead of Window in
UI Events IDL since 2018:
816158b4aa
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
Now that the heap has no knowledge about a JavaScript realm and is
purely for managing the memory of the heap, it does not make sense
to name this function to say that it is a non-realm variant.
Having the text cursor disappear during rapid continuous editing is
quite jarring, so let's make sure we always restart the blink cycle
whenever the user performs some kind of editing action in a frame.
Problem:
- `(void)` simply casts the expression to void. This is understood to
indicate that it is ignored, but this is really a compiler trick to
get the compiler to not generate a warning.
Solution:
- Use the `[[maybe_unused]]` attribute to indicate the value is unused.
Note:
- Functions taking a `(void)` argument list have also been changed to
`()` because this is not needed and shows up in the same grep
command.
FrameLoader now begins by constructing a DOM::Document, and then builds
a document tree inside it based on the MIME type. For text/html we pass
control to the HTMLDocumentParser as before.
This gives us access to things like window.alert() during parsing.
Fixes#3973.
Instead of storing them as CSS::Lengths, we now store the resolved
values for margin/padding/border/offset top/right/bottom/left with
each Layout::NodeWithStyleAndBoxModelMetrics.
This simplifies a lot of code since it's no longer necessary to
resolve values before using them.
This isn't entirely symmetrical with on_load_start as it will also fire
on reloads and back/forward navigations. However, it's good enough for
some basic use cases, and we can do more sophisticated notifications
later on when we need them.
Layout was using an outdated viewport rect that we set *after* doing
a layout due to resize. That meant that layout-in-response-to-resize
was always lagging behind the current size of the view.
The root of this problem was how Frame kept both a viewport rect
(with both scroll offset and size) and a frame size. To fix this,
only store the viewport scroll offset, and always use the frame size.
This way they can't get out of sync and the problem goes away. :^)
Fixes#4250.
