If the left-hand side of the tab is already occupied with an audio state
button, we would add a second button to the right-hand side. Prevent
that by checking if the occupant is our audio state button.
This implementation uses a really basic WebView to update stats once
a second. In the future it might make more sense to both move the
details into LibWebView, and to create a native widget for each platform
to remove the overhead of having an extra WebView.
On macOS, the "close tab" button is on the left, so we should place the
audio state button on the right to avoid conflict. Rather than an OS
ifdef, we do this by detecting if the left side is occupied.
We were errantly always referring to the active tab when the audio play
state changed, and when clicking a tab's audio state button, by way of
BrowserWindow::view().
It turns out we also can't copy / rely on the tab index provided to the
signal in any asynchronous context. If the tabs are rearranged, so are
their indices. Instead, capture a pointer to the tab of interest - this
should be safe as we wouldn't be able to click a tab's audio button if
that tab no longer exists.
With this change, we can click the audio button from any tab in the Qt
chrome, and re-arrange tabs at will. The AppKit and Serenity chromes do
not have this issue.
We already display a speaker icon on tabs which are playing audio. This
allows the user to click that icon to mute the tab, at which point the
icon is replaced with a muted speaker icon.
We would previously hide the icon when audio stopped playing. We now do
this only if the tab isn't muted. If it is muted, the muted speaker icon
remains on the tab so that the page isn't stuck in a muted state.
When audio begins playing, add a button to the left of the favicon with
a speaker icon to indicate which tab is playing audio. This button is
currently disabled, but in the future may be used to mute the tab.
This ensures we consistently show a favicon and that we update the title
to at least display the page URL when there isn't a <title> tag. We
would otherwise continue displaying the previous page's title.
This URL library ends up being a relatively fundamental base library of
the system, as LibCore depends on LibURL.
This change has two main benefits:
* Moving AK back more towards being an agnostic library that can
be used between the kernel and userspace. URL has never really fit
that description - and is not used in the kernel.
* URL _should_ depend on LibUnicode, as it needs punnycode support.
However, it's not really possible to do this inside of AK as it can't
depend on any external library. This change brings us a little closer
to being able to do that, but unfortunately we aren't there quite
yet, as the code generators depend on LibCore.
The code to convert a Gfx::IntPoint to a QPoint adjusted for the device
pixel ratio is a bit of a mouthful, and will be needed outside of Tab,
so move it to a helper that can be reused.
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.
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.
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.
