Previously, calling `.right()` on a `Gfx::Rect` would return the last
column's coordinate still inside the rectangle, or `left + width - 1`.
This is called 'endpoint inclusive' and does not make a lot of sense for
`Gfx::Rect<float>` where a rectangle of width 5 at position (0, 0) would
return 4 as its right side. This same problem exists for `.bottom()`.
This changes `Gfx::Rect` to be endpoint exclusive, which gives us the
nice property that `width = right - left` and `height = bottom - top`.
It enables us to treat `Gfx::Rect<int>` and `Gfx::Rect<float>` exactly
the same.
All users of `Gfx::Rect` have been updated accordingly.
The goal here is to reduce the amount of WebContent client APIs that are
duplicated across every ViewImplementation. Across our three browsers,
we currently:
Ladybird - Mix some AK::Function callbacks and Qt signals to notify
tabs of WebContent events.
Browser - Use only AK::Function callbacks.
headless-browser - Drop most events on the floor.
Instead, let's only use AK::Function callbacks across all three browsers
to propagate events to tabs. This allows us to invoke those callbacks
directly from LibWebView instead of all three browsers needing to define
a trivial `if (callback) callback();` override of a LibWebView virtual
function. For headless-browser, we can simply not set these callbacks.
As a first pass, this only converts WebContent events that are trivial
to this approach. That is, events that were simply passed onto the tab
or handled without much fuss.
This is to match Browser, where ownership of all "subwidgets" is placed
on the tab as well. This further lets us align the web view callbacks to
match Browser's OOPWV as well, which will later let us move them into
the base LibWebView class.
Note that the real implementations of these functions are:
notify_server_did_output_js_console_message
notify_server_did_get_js_console_messages
Which have the same method bodies as these unused variants.
The implementations of handle_web_content_process_crash and
take_screenshot are exactly the same across Browser and Ladybird. Let's
reduce some code duplication and move them to LibWebView.
This just sets up the IPC to notify the browser process of context menu
requests on video elements. The IPC contains a few pieces of information
about the state of the video element.
While resizing, we now pad the shared bitmap allocations with 256 pixels
extra in both axes. This avoids churning through huge allocations for
every single resize step.
We also don't reallocate at all when making the window smaller.
3 seconds after the user stops resizing, we resize the backing stores
again so they fit the window perfectly.
This fixes an unpleasant visual glitch when resizing the window.
When the user makes our QAbstractScrollArea larger, the scroll bars can
end up with negative values, which we were happily forwarding to the
WebContent process and asking it to paint the whole page at an offset.
This adds "Inspect Element" (currently the only entry) to the context
menu for the page, which will do what you expect (most of the time),
and bring up the Inspector with hovered element selected.
Now that the Core::EventLoop is driven by a QEventLoop in Ladybird,
we don't need to patch LibWeb with Web::Platform plugins.
This patch removes EventLoopPluginQt and TimerQt.
Note that we can't just replace the Web::Platform abstractions with
LibCore stuff immediately, since the Web::Platform APIs use
JS::SafeFunction for callbacks.
Not a single client of this API actually used the event mask feature to
listen for readability AND writability.
Let's simplify the API and have only one hook: on_activation.
This aligns the Ladybird console implementation with the Browser console
a bit more, which uses OutOfProcessWebView for rendering console output.
This allows us to style the console output to try and match the system
theme.
Using a WebContentView is simpler than trying to style the old QTextEdit
widget, as the console output is HTML with built-in "-libweb-palette-*"
colors. These will override any color we set on the QTextEdit widget.
This adds a -P option to run Ladybird under callgrind. It starts with
instrumentation disabled. To start capturing a profile (once Ladybird
has launched) run `callgrind_control -i on` and to stop it again run
`callgrind_control -i off`.
P.s. This is pretty much stolen from Andreas (and is based on the patch
everyone [that wants a profile] have been manually applying).
Generate handle UUID for top-level context that is going to
run in created WebContent process and sent it over IPC.
Co-authored-by: Timothy Flynn <trflynn89@pm.me>
Currently, on Serenity, we connect to WebDriver from the browser-side of
the WebContent connection for both Browser and headless-browser.
On Lagom, we connect from within the WebContent process itself, signaled
by a command line flag.
This patch changes Lagom browsers to connect to WebDriver the same way
that Serenity browsers do. This will ensure we can do other initializers
in the same order across all platforms and browsers.
There isn't a 1:1 equivalent for all ColorRoles between Qt and LibGfx,
but we can at least make an effort to translate the various QPalette
preferred colors.
This makes text selection look a lot more "native" in Ladybird. :^)
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>.
