WebDriver currently uses the WebContent::ConnectionFromClient IPC class
directly for these features. To support headless-browser, WebDriver will
instead need to rely on PageClient to provide these.
Currently, all handling of pending dialogs occurs in PageHost. In order
to re-use this functionality to run WebDriver in a headless move, move
it to Page.
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.
(And BrowsingContextGroup had to come along for the ride as well.)
This solves a number of nasty reference cycles between browsing
contexts, history items, and their documents.
This includes punting on the actual file picker implementation all the
way out to the PageClient. It's likely that some of the real details
should be implemented somewhere closer, like the BrowsingContext or the
Page, but we'll get there.
For now, this allows https://copy.sh/v86 to load the emulation of the
preselected images all the way until it hits a call to
URL.createObjectURL.
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 used by window.close() programmatically, but of course the user
can also decide to close a top-level browsing context at any time by
closing the tab.
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.
This patch implements the "create a new browsing context" function from
the HTML spec and replaces our existing logic with it.
The big difference is that browsing contexts now initially navigate to
"about:blank" instead of starting out in a strange "empty" state.
This makes it possible for websites to create a new iframe and start
scripting inside it right away, without having to load an URL into it.
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.
To achieve this goal:
- The Browser unveils "/tmp/portal/filesystemaccess"
- Pass the page through LoadRequest => ResourceLoader
- ResourceLoader requests a file to the FileSystemAccessServer via IPC
- OutOfProcessWebView handles it and sends a file descriptor back to
the Page.
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 is now the source of truth for 'user enabled/disabled scripting',
but it has to ask the window's page, which actually stores the setting.
Also use this new functionality in two places where it was previously
marked as a FIXME.
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()
