Since 9e2bd9d261a8c0c1b5eeafde95ca310efc667204, the OOPWV has been
consuming all mouse and keyboard events, preventing action shortcuts
from working. So let's fix that. :^)
OOPWV now queues up input events, sending them one at a time to the
WebContent process and waiting for the new
`did_finish_handling_input_event(bool event_was_accepted) =|` IPC call
before sending the next one. If the event was not accepted, OOPWV
imitates the usual event bubbling: first passing the event to its
superclass, then to its parent widget, and finally propagating to any
Action shortcuts.
With this, shortcuts like Ctrl+I to open Browser's JS console work
again, except when a contenteditable field is selected. That's a
whole separate stack of yaks.
Co-authored-by: Zaggy1024 <zaggy1024@gmail.com>
If the page's URL is changed from within the WebContent process (e.g.
window.location.href is set from JavaScript, or a navigation is started
from WebDriver), we would not store the URL at all within OOPWV. This
prevented actions like reloading from working properly, as the browser
would reload whatever URL was previously entered in the URL box.
The way in which dialogs should be handled is configurable by the driver
capabilities object, which we don't support yet. So this implements just
the default mode to dismiss the dialog and return an error if there is
one open.
In the OOPWV, this means we need to refer to the dialog after it has
been open, so we now hold a pointer to whatever dialog is open.
Currently, the WebContent process is completely blocked while waiting
for a response to a dialog request. This patch allows the IPC event loop
to continue executing while only blocking the HTML event loop.
This will allow other processes like WebDriver to continue to operate on
the WebContent process while a dialog is open.
Requests to maximize and minimize Browser windows will be coming from
the WebContent process rather than the WebDriver process. Add hooks to
propagate these requests back up to the Browser.
Requests to restore, resize, and reposition Browser windows will be
coming from the WebContent process rather than the WebDriver process.
Add hooks to propagate these requests back up to the Browser.
The spec notes "The specification does not guarantee that the resulting
window size will exactly match that which was requested", so these new
methods return the actual new size/position.
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.
Note that even though there is no response, this IPC has to be
synchronous to allow all scroll events to trigger before returning to
the calling WebDriver process.
To use the `GET /session/{id}/element/{id}/css/{property name}`
WebDriver endpoint, two new IPC calls through the Browser are
implemented:
- get_active_documents_type returns the type of the active document,
which is either "xml" or "html"
- get_computed_value_for_element returns the computed CSS value (as
String) for the given element and CSS property name
This extends the IPC calls `get_document_element` and
`query_selector_all` to be usable by the WebDriver. For this the
`WebDriverConnection` provides the same interfaces and takes care of
routing the data through the Browser.
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.
Also moves WebContentClient and the references to the generated IPC
descriptions, since they are all components of OutOfProcessWebView.
This patch has no functional changes.
2022-05-15 12:17:36 +02:00
Renamed from Userland/Libraries/LibWeb/OutOfProcessWebView.cpp (Browse further)
