LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString,
so that is as far as these changes can reach.
The one change which isn't just a DeprecatedString to String replacement
is handling the "null" prompt response. We previously checked for the
null DeprecatedString, whereas we now represent this as an empty
Optional<String>.
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.
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.
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 :^)
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>
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.
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.
After this change, LibWeb now expects Web::ImageDecoding::Decoder to be
pre-initialized with a concrete implementation before using the webpage.
The previous implementation, based on the ImageDecoder service, has been
provided directly through an adapter in LibWebClient, and is now used as
the default value by WebContent.
This Adds an element size preview widget to the inspector widget
in a new tab. This functions similar to chrome and firefox and
shows the margin, border, padding, and content size of the selected
element in the inspector.
The colors for the size preview widget are taken from the chrome
browser.
This is in preparation for implementing JS scrolling functions, which
specify both x and y scrolling deltas. The visible behavior has not
changed.
Also, moved the "mouse wheel delta * 20" calculation to the
`EventHandler` since the JS calls will want to work directly in pixels.
This patch removes the following WebContent IPC calls, which are no
longer used:
- `Server::js_console_initialize()`
- `Client::did_js_console_output()`
This patch introduces three new IPC calls for WebContent:
- `Client::did_output_js_console_message(index)`:
Notifies the client that a new console message was logged.
- `Server::js_console_request_messages(start_index)`:
Ask the server for console messages starting at the given index.
- `Client::did_get_js_console_messages(start_index, types, messages)`:
Send the client the messages they requested.
This mechanism will replace the current
`Client::did_js_console_output()` call in the next few commits. This
will allow us to display messages in the console that happened before
the console was opened.
Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to
WebContentClient.
These two async methods form a request & response for requesting a JSON
representation of the Content's DOM tree.
This patch removes the IPC endpoint numbers that needed to be specified
in the IPC files. Since the string hash is a (hopefully) collision free
number that depends on the name of the endpoint, we now use that
instead. :^)
Additionally, endpoint magic is now treated as a u32, because endpoint
numbers were never negative anyway.
For cases where the endpoint number does have to be hardcoded (a current
case is LookupServer because the endpoint number must be known in LibC),
the syntax has been made more explicit to avoid confusing those
unfamiliar. To hardcode the endpoint magic, the following syntax is now
used:
endpoint EndpointName [magic=1234]
This patch removes the IPC endpoint numbers that needed to be specified
in the IPC files. Since the string hash is a (hopefully) collision free
number that depends on the name of the endpoint, we now use that
instead. :^)
To protect the main Browser process against nefarious cookies, parse the
cookies out-of-process and then send the parsed result over IPC to the
main process. This way, if the cookie parser blows up, only that tab
will be affected.
To implement the HttpOnly attribute, the CookieJar needs to know where a
request originated from. Namely, it needs to distinguish between HTTP /
non-HTTP (i.e. JavaScript) requests. When the HttpOnly attribute is set,
requests from JavaScript are to be blocked.
In single process mode, the browser will display a page's favicon in
both the location bar and tab. This adds the same support for multi-
process mode.
When a mousewheel scroll event isn't handled by the web content
itself (e.g. an overflowed box or similar), the event needs to get
passed back up to the OutOfProcessWebView.
