With current architecture every window has its own WebContent process
and there is one WebDriver process that is responsible for talking to
all opened windows. It thus make sense to manage open windows from
WebDriver process instead of WebContent process that is not supposed
to know about all other opened WebContent processes.
This mostly reverts 826d5f8f9a but also
adds `web_content_connection` to window structure and window id
generation (currently out of spec).
With these changes `get_window_handles`, `switch_to_window` and
`close_window` start to actually switch, close and returned handles
of currently opened windows.
This changes the parameters parsed from a WebDriver HTTP request to
String for transferring over IPC. Conveniently, most locations these
were ultimately passed to only need a StringView.
This moves the actual launching of browser windows to the WebDriver main
file. This will allow Ladybird to specify its own callback and re-use
Serenity's Session class.
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 :^)
Still some TODOs here:
* We don't handle all capabilities (e.g. proxy)
* We don't match the capabilities against the running browser
But this will parse the capabilities JSON object received from the
WebDriver client.
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.
Success responses are meant to be wrapped in a JSON object with a single
"value" key. Instead of doing this in both WebContent and WebDriver, do
it once in LibWeb.
We are expected to return the list of open handles after closing the
current handle. Also just return a WebDriver::Response instead of a
wrapped Error variant.
There are a couple changes here from the existing Get All Cookies
implementation.
1. Previously, WebDriver actually returned *all* cookies in the cookie
jar. The spec dictates that we only return cookies that match the
document's URL. Specifically, it calls out that we must run just the
first step of RFC 6265 section 5.4 to perform domain matching.
This change adds a special mode to our implementation of that section
to skip the remaining steps.
2. We now fill in the SameSite cookie attribute when serializing the
cookie to JSON (this was a trival FIXME that didn't get picked up
when SameSite was implemented).
