After ea682207d0, we need Userland/
included directly in these application executables. This only impacts
the build with Ladybird/CMakeLists.txt as the top level CMakeLists, as
the Lagom/ directory includes Userland/ globally.
It's no change in application behavior to have these objects owned by
the function-scope static map in Protocol.cpp, while allowing us to
remove some ugly FIXMEs from time immemorial.
The AppKit chrome currently handles all input events before selectively
forwarding those events to WebContent. This means that WebContent does
not see events like cmd+c.
Here, we make use of LibWebView's input handling and wait for LibWebView
to inform the chrome that it should handle the event itself.
The Qt chrome currently handles all input events before selectively
forwarding those events to WebContent. This means that WebContent does
not see events like ctrl+c.
Here, we make use of LibWebView's input handling and wait for LibWebView
to inform the chrome that it should handle the event itself.
It aligns better with the Filesystem Heirarchy Standard[1] to put our
program-specific helper programs that are not intended to be executed by
the user of the application in $prefix/libexec or in whatever the
packager sets as the CMake equivalent. Namely, on Debian systems this
should be /usr/lib/Ladybird or similar.
[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrlibexec
Now we will only load resources from $build/share/Lagom. On macOS, we
load from the bundle directory Contents/Resources instead. This
simplifies the commands and environment variables needed to execute
Ladybird from the build directory, and makes our install setup less
awkward for distributions and packagers.
Don't put them in bin/ and then copy them to the bundle dir later, as
this means that they only get updated in the bundle directory if the
Ladybird binary itself needs updated. Which is not a fun workflow if you
are working on WPT and want to hack on the WebDriver binary.
QUrl::toString reverses the Unicode->ASCII conversion that already
occurred here. The text of m_location_edit is already in the format we
expect, so let's just convert QString->AK::URL directly, instead of
taking the detour QString->QUrl->AK::URL
Some Wayland compositors have support of fractional-scale-v1 protocol.
The protocol allows compositor to announce a preferred fractional scale
on a per-wl_surface basis. Qt forwards these Wayland events to an
application using a usual DevicePixelRatioChange event. However, in
contrast to the other platforms, this DevicePixelRatioChange event is
issued directly on widgets and not screens. Additionally, the exact
fractional scale is stored in QWindow object and not the current screen.
Note that in theory it is possible to obtain per-screen fractional
scaling on Wayland by interpolating data provided by wl_output and
xdg_output events but qtwayland does not do that.
If fractional-scale-v1 is not available, qtwayland will still fire
per-Widget DevicePixelRatioChange events, but, obviously, with the
per-screen possibly larger ceiled scaling.
This whole thing makes handling DPI changes on Wayland really simple.
All we need to do is to intercept DevicePixelRatioChange events firing
on QWindow objects and call the old device_pixel_ratio_changed handler
with the window's devicePixelRatio(). The only caveat here is not forget
to always set QWidget's parent before calling devicePixelRatio() on it.
Previously, on systems where pressing Enter would generate "\r\n", only
the '\r' character was being sent to the event handler. This change
ensures consistent behavior across platforms regardless of their native
line ending characters.
The IPC layer between chromes and LibWeb now understands that multiple
top level traversables can live in each WebContent process.
This largely mechanical change adds a billion page_id/page_index
arguments to make sure that pages that end up opening new WebViews
through mechanisms like window.open() still work properly with those
extra windows.
We currently bundle AK with LibCore on Lagom. This means that to use AK,
all libraries must also depend on LibCore. This will create circular
dependencies when we create LibURL, as LibURL will depend on LibUnicode,
which will depend on LibCore, which will depend on LibURL.
Instead of spawning these processes from the WebContent process, we now
create them in the Browser chrome.
Part 1/N of "all processes are owned by the chrome".
These IPCs are different than other IPCs in that we can't just set up a
callback function to be invoked when WebContent sends us the screenshot
data. There are multiple places that would set that callback, and they
would step on each other's toes.
Instead, the screenshot APIs on ViewImplementation now return a Promise
which callers can interact with to receive the screenshot (or an error).
According to Qt documentation, destruction of a QObject's children may
happen in any order. In our case, the Tab's WebContentView is deleted
before its InspectorWidget. The InspectorWidget performs cleanup on that
WebContentView in its destructor; this causes use-after-free since it
has already been destroyed.
From reading Qt threads, if a particular destruction order is required,
it is okay to enforce that order with manual `delete`s. This patch does
so with the InspectorWidget to ensure it is deleted before the
WebContentView. Qt's object ownership is okay with this - it will remove
the InspectorWidget from the Tab's children, preventing any double
deletion.
