This starts moving code equally shared between the OOPWV and Ladybird
WebContentView implementations to WebView::ViewImplementation, beginning
with the client state.
By setting this hint, you indicate to OOPWV that the content inside will
scale itself to the viewport size. In such situations, it's fine for
OOPWV to reuse a scaled version of an outdated backing store while the
view is being resized.
These functions return the deprecated `Core::File` class, so let's mark
it as such to avoid possible confusion between future non try_*
functions which will use Core::Stream family classes and to possibly
grab someone's attention. :^)
This patch also stubs out notify_server_did_get_accessiblity_tree in
ladybird since ViewImplementation now has it. However, this feature
is still immature, so just stubbing out in ladybird for now. Once we
have more robust support in Serenity (namely ARIA properties/state
and accessible names and descriptions) we can port this
functionality over.
This fixes a few things I noticed whilst working on the inspector
for Ladybird.
1.
The computed and resolved values were being passed swapped around
from the inspect_dom_node() IPC call. I.e. computed values were
passed as resolved values and vice versa. This was then fixed by
swapping them again in the InspectorWidget (two errors canceled out).
2.
Resolved values were called "specified values" seemingly only in the
inspect_dom_node() IPC calls. This was a little confusing so I've
renamed them to back to "resolved values" for consistency.
3.
The inspector took and stored the DOM JSON strings unnecessarily,
all the models immediately parse the JSON and don't need the strings
to hang around.
This currently doesn't work when running Serenity through QEMU, as it
doesn't pass the side button events over to Serenity due to some bug or
missing feature.
Updating cookies through these hooks happens in one of two manners:
1. Through the Browser's storage inspector.
2. Through WebDriver's delete-cookies operation.
In (1), we should not restrict ourselves to being able to delete cookies
for the current page. For example, it's handy to open the inspector from
the welcome page and be able to delete cookies for any domain.
In (2), we already are only interacting with cookies that have been
matched against the document URL.
This will make it easier to support both string types at the same time
while we convert code, and tracking down remaining uses.
One big exception is Value::to_string() in LibJS, where the name is
dictated by the ToString AO.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
We now replace the current history entry if the page-load has been
caused because of a redirect. This makes it able to traverse the
history if one of the entries redirects you, which previously
caused an infinite history traversion loop.
Previously we labeled redirects as normal FrameLoader::Type::Navigation,
now we introduce a new FrameLoader::Type::Redirect and label redirects
with it. This will allow us to handle redirects in the browser
differently (such as for overwritting the latest history entry when a
redirect happens) :^)
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.
