This moves setting the navigator.webdriver flag from after WebContent
creates the WebDriver connection, to its own IPC to be triggered from
WebDriver. This is closer to the spec, but mostly serves as an easy
test to validate the connection.
First, this moves the WebDriver socket to the /tmp/websocket/ directory,
as WebDriver now creates multiple sockets per session. Those sockets are
now created with Core::LocalServer rather than manually setting up the
listening sockets (this was an existing FIXME which resolved some issues
I was hitting with creating a second listening socket).
WebDriver passes both socket paths to Browser via command line. Browser
continues to connect itself via one socket path, then forwards the other
socket path to the WebContent process created by the OOPWV. WebContent
then connects to WebDriver over this path.
WebContent will temporarily set the navigator.webdriver flag to true
after connecting to WebDriver. This will soon be moved to its own IPC to
be sent by WebDriver.
This just sets up the infrastructure for the WebContent process to house
WebDriver IPCs, and adds an IPC for WebContent to create the WebDriver
connection. The WebDriverConnection class inside WebContent ultimately
will contain most of what is currently in WebDriver::Session (so the
copyright attributions are copied here as well).
The socket created by WebDriver is currently /tmp/browser_webdriver
(formatted with some IDs). This will be moved to the /tmp/webdriver
folder, as WebDriver will create multiple sockets to communicate with
both Browser and WebContent as the IPCs are iteratively moved to
WebContent. That path is unveiled here, though it is unused as of this
commit.
This is essentially an ErrorOr<JsonValue, Web::WebDriver::Error> class.
Unfortunately, that ErrorOr would not be default-constructible, which is
required for the generated IPC classes. So this is a thin wrapper around
a Variant<JsonValue, Web::WebDriver::Error> to emulate ErrorOr.
We still log the error (perhaps in the future, we will only want to log
the error if there is no handler). But this allows callers to actually
handle errors to e.g. unblock waiters.
I wrote these tests a while ago while trying to improve the bytecode,
but didn't end up making them pass and gave up. They work in AST
interpreter mode, so we can have them in now to have them around for
anyone who wants to try and make them pass in bytecode.
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>
This patch mitigates a rough gradient for the brush tool with a low
hardness. Previously the gradient alpha value was truncated by the type
conversion to int. Now the desired alpha value is scaled up to mitigate
the information loss due to type conversion which results in a much
smoother gradient.
The container appears to be null for certain elements such as the
"update your browser" box when clicking on the document during certain
parts of loading. Skipping it works fine, but should obviously be
fixed, so it prints a debug output when this happens.
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.
process_the_iframe_attributes already causes a navigation, so this
would cause a double navigation and blow away any setup that JS may
have done from events fired in process_the_iframe_attributes.
This was a missing spec step. This prevents it navigating to
about:blank, which will blow away the document and thus any setup that
was done in the iframe load event.
These are required for hit testing the document in Google Docs. If they
aren't defined, the Google Docs hit test code will add undefined to
certain values, causing them to turn into NaN. This causes NaNs to
propagate through their hit test code, which eventually makes it
infinitely loop.
