The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
Because of interdependencies between DOM::Event and UIEvents::MouseEvent
to template function fire_an_event() in WebDriverConnection.cpp, the
commit: 'LibWeb: Make factory methods of UIEvents::MouseEvent fallible'
have been squashed into this commit.
Before this patch, we were expressing the current selection as a range
between two points in the layout tree. This was a made-up concept I
called LayoutRange (2x LayoutPosition) and as it turns out, we don't
actually need it!
Instead, we can just use the Selection API from the Selection API spec.
This API expresses selection in terms of the DOM, and we already had
many of the building blocks implemented.
To ensure that selections get visually updated when the underlying Range
of an active Selection is programmatically manipulated, Range now has
an "associated Selection". If a range is updated while associated with
a selection, we recompute layout tree selection states and repaint the
page to make it user-visible.
This simplifies the ownership model between DOM/layout/paint nodes
immensely by deferring to the garbage collector for figuring out what's
live and what's not.
DeprecatedFlyString relies heavily on DeprecatedString's StringImpl, so
let's rename it to A) match the name of DeprecatedString, B) write a new
FlyString class that is tied to String.
Unlike client{X,Y} which is relative to the current viewport, these
offsets are relative to the left edge of the document (i.e they take
scroll offset into account).
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
The returned bool should be true if the event was consumed, aka if we
should ignore it. But `dispatch_event()` returns true if
you *shouldn't* ignore it, so we have to invert that return value.
This makes hovering over the link in the following HTML snippet work,
i.e. the tooltip is shown and the link target is shown at the bottom
of the browser window:
<html lang="en"><head><style>
.site-link{display:inline-block}
.site-link:before{content:"derp"}
.site-link::after{content:"";display:block}
</style></head><body><a class="site-link" href="#"
title="Tooltip, maybe!"></a>
Google Docs focuses a "text event target" iframe using Window.focus on
the iframe's contentWindow. Doing so makes the iframe's document the
focused element we have to fire text events at. However, in the top
level browsing context, the focused element is still the iframe, so we
have to repeat the keyboard event steps but with the iframe's nested
browsing context instead.
Since our hit testing mechanism gives you the Paintable under the mouse
cursor, we can't just give up if that paintable doesn't have a
corresponding DOM node. That meant that generated content like pseudo-
elements didn't generate mouse events at all.
Fix this by making a dom_node_for_event_dispatch() helper function that
finds a suitable DOM node when given a paintable. This first cut is very
naive, and there's probably more we should do, but we have to start
somewhere. :^)
This removes a set of complex reference cycles between DOM, layout tree
and browsing context.
It also makes lifetimes much easier to reason about, as the DOM and
layout trees are now free to keep each other alive.
These classes only needed Window to get at its realm. Pass a realm
directly to construct Crypto, Encoding, HRT, IntersectionObserver,
NavigationTiming, Page, RequestIdleCallback, Selection, Streams, URL,
and XML classes.
This is a monster patch that turns all EventTargets into GC-allocated
PlatformObjects. Their C++ wrapper classes are removed, and the LibJS
garbage collector is now responsible for their lifetimes.
There's a fair amount of hacks and band-aids in this patch, and we'll
have a lot of cleanup to do after this.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
This improves our spec compliance by allowing the user to click
non-element nodes (like text) and having the click be registered with
the parent element (like a div or button). This makes Fandom's cookie
accept button work if you click the text. Additionally, the events test
page contains a test to check the target element, which would previously
not exist when we fired the event at a non-element.
The WebView url wouldn't update so reload in Tab would still use the
previous URL before any left click navigation.
I am unsure if there was any good reason not to dispatch the event when
there are no modifiers.
This commit moves a couple more special cases in mouse event handling to
handle_mouseup. Additionally, it gets rid of the special casing with
should_dispatch_event and only fires a click event to the EventTarget
when the left mouse button is clicked. Finally it restores the link
context menu callback that was lost during 0fc8c65.
This commit moves the regular handling of links to the anchor elements'
activation behavior, and implements a few auxiliary algorithms as
defined by the HTML specification.
Note that certain things such as javascript links, fragments and opening
a new tab are still handled directly in EventHandler, but they have been
moved to handle_mouseup so that it behaves closer to how it would if it
was entirely up-to-spec.
This is a convenience accessor to avoid having to say this everywhere:
result.paintable->layout_node().dom_node()
Instead, you can now do:
result.dom_node()
