Store the ratio between device and CSS pixels on the PaintContext, so
that it can convert between the two.
Co-authored-by: MacDue <macdue@dueutil.tech>
...and also for hit testing, which is involved in most of them.
Much of this is temporary conversions and other awkwardness, which
should resolve itself as the rest of LibWeb is converted to these new
types. Hopefully. :thousandyakstare:
Instead of creating a new global object and proxying everything through
it, we now evaluate console inputs inside a `with` environment.
This seems to match the behavior of WebKit and Gecko in my basic
testing, and removes the ConsoleGlobalObject which has been a source of
confusion and invalid downcasts.
The globals now live in a class called ConsoleGlobalObjectExtensions
(renamed from ConsoleGlobalObject since it's no longer a global object).
To make this possible, I had to add a way to override the initial
lexical environment when calling JS::Interpreter::run(). This is plumbed
via Web::HTML::ClassicScript::run().
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.
`Core::Stream::File` shouldn't hold any utility methods that are
unrelated to constructing a `Core::Stream`, so let's just replace the
existing `Core::File::exists` with the nicer looking implementation.
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 :^)
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>
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.
WebDriverConnection can now work with PageClient's virtual interface.
This will allow constructing a WebDriverConnection from the PageClient
implementation in headless-browser.
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.
When timeouts are implemented, the start node used to find elements may
not remain valid for the entire duration of the timeout. For example,
the active document element may change, or the start node may be removed
from the DOM.
To handle this, we will need to re-evaluate the start node on each
iteration of the find() operation. This patch wraps the steps to do so
in a lambda to be executed on each iteration.
These are based on the ones in Firefox:
`$(selector, element = document)`:
Equivalent to `element.querySelector(selector)`.
`$$(selector, element = document)`:
Equivalent to `element.querySelectorAll(selector)`.
This holds the return value of the expression that was last entered into
the browser console. If that last expression returned an error of some
kind, `$_` will be `undefined`. This matches the behaviour in Firefox.
This allows us to expose extra functions and properties to the console,
such as `$0`, without them being available to website scripts.
`ConsoleEnvironmentSettingsObject` is basically a stub, since we require
an `EnvironmentSettingsObject` but it has abstract methods.
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.
This moves Get Window Handle, Close Window, and Get Window Handles over
to WebContent so they may be implemented closer to the spec and be used
by Ladybird.
