Sometimes I like to play around with running Ladybird tests using full
blown Ladybird instead of just headless browser to interactively mess
around with the test page. One problem with this is that the internals
object is not exposed in this mode.
This commit supports this usecase by adding an option to specifically
expose the internals object without needing to run headless-browser
in test mode.
When launched with the new --enable-idl-tracing option, we now log
every call to web platform APIs declared via IDL, along with the
arguments passed.
This can be very helpful when trying to figure out what a site is
doing, especially if it's not doing what you'd expect.
When running with --log-all-js-exceptions, we will print the message
and backtrace for every single JS exception that is thrown, not just
the ones nobody caught.
This can sometimes be very helpful in debugging sites that swallow
important exceptions.
Before this change we had to keep session history on browser side to
calculate a url for back/forward/reload action.
Now, with a mature enough implementation of navigation algorithms from
the specification, there is no need to use
history on the browser side to calculate navigation URLs because:
- Traversable navigable owns session history that is aware of all
navigations, including those initiated by History API and Navigation
API
- TraversableNavigable::traverse_the_history_by_delta() uses
traversable's history to calculate the next URL based on delta, so
there is no need for UI to keep sesion history.
In the future, we will likely want to add a way to pull session history
from WebContent to make it browsable from the UI.
The previous name was extremely misleading, because the call is used for
pushing or replacing new session history entry on chrome side instead of
only changing URL.
Instead of treating reloading as a regular navigation by using
load_url(), now we invoke a navigable reloading algorithm implemented
from the spec.
Now both reloading triggered from UI and location.reload() will use the
same code path.
Currently the `<select>` dropdown IPC uses the option value attr to
find which option is selected. This won't work when options don't
have values or when multiple options have the same value. Also the
`SelectItem` contained so weird recursive structures that are
impossible to create with HTML. So I refactored `SelectItem` as a
variant, and gave the options a unique id. The id is send back to
`HTMLSelectElement` so it can find out exactly which option element
is selected.
This adds a button on the right side of the location bar to create a new
tab.
Ideally, we would actually use QTabWidget::setCornerWidget to put this
button in the tab bar. But it is surprisingly difficult to make that
look nice on all platforms. Even if we ignore macOS, the CSS to make the
button look right on KDE Plasma may not work well on Gnome. So for now,
this location next to the location bar is horizontally the same that it
would be in the tab bar at least.
We currently do this already when the last tab is closed via the ctrl-W
shortcut. Move the logic for this to BrowserWindow::close_tab so that we
also close the window when the tab is closed via its close button.
By default, Qt will grow the width of a tab button to fit the title text
of the tab. For long titles or file:// URLs, this looks rather bad. This
sets a min/max tab width to prevent such infinite growth.
To do this, we have to subclass both QTabWidget and QTabBar, because the
functions to be called/overridden are protected.
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.
With this change, chrome no longer has to ask the WebContent process
to paint the next frame into a specified bitmap. Instead, it allocates
bitmaps and sends them to WebContent, which then lets chrome know when
the painting is done.
This work is a preparation to move the execution of painting commands
into a separate thread. Now, it is much easier to start working on the
next frame while the current one is still rendering. This is because
WebContent does not have to inform chrome that the current frame is
ready before it can request the next frame.
Additionally, as a side bonus, we can now eliminate the
did_invalidate_content_rect and did_change_selection IPC calls. These
were used solely for the purpose of informing chrome that it needed to
request a repaint.
This commit un-deprecates DeprecatedString, and repurposes it as a byte
string.
As the null state has already been removed, there are no other
particularly hairy blockers in repurposing this type as a byte string
(what it _really_ is).
This commit is auto-generated:
$ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \
Meta Ports Ladybird Tests Kernel)
$ perl -pie 's/\bDeprecatedString\b/ByteString/g;
s/deprecated_string/byte_string/g' $xs
$ clang-format --style=file -i \
$(git diff --name-only | grep \.cpp\|\.h)
$ gn format $(git ls-files '*.gn' '*.gni')
If the Inspector widget already exists, be sure to inspect the page when
it is re-opened. However, this should be a no-op if the page was already
inspected (as any existing Inspector will be reset if a new page load
began).
Note this is not an issue in the AppKit chrome.
It was a bit short-sighted to combine the tag and attribute names into
one string when the Inspector requests a context menu. We will want both
values for some context menu actions. Send both names, as well as the
attribute value, when requesting the context menu.
When a QObject subclass (widgets, etc.) are provided a parent, then
ownership of that object is passed to the parent. Similarly, objects
added to a QLayout are owned by the layout.
Thus, do not store these objects in an OwnPtr.
QString is UTF-16, thus QString::size returns the number of UTF-16 code
units. Thus, we would fail to perform, for example:
ak_string_from_qstring(QString("😀"));
Which is 2 UTF-16 code units, but 4 UTF-8 code units.
There's no need for 2 overloads for String and DeprecatedString, we can
just use a StringView. This also avoids some cases of needlessly
allocating a DeprecatedString from a StringView when calling this
method.
Ladybird on Serenity currently only uses F12, and on other platforms
only uses ctrl+shift+I. Most browsers support both hotkeys, so let's do
the same for consistency.
Note that the AppKit chrome cannot support both shortcuts. macOS does
not allow setting multiple "key equivalent" strings on an action. There
are some questionable hacks we could do to support this eventually, but
for now, just ctrl+shift+I is supported on macOS.
It is currently a bit messy to pass these options along from main() to
where WebContent is actually launched. If a new flag were to be added,
there are a couple dozen files that need to be updated to pass that flag
along. With this change, the flag can just be added to the struct, set
in main(), and handled in launch_web_content_process().
This was used to provided base functionality for model-based chromes for
viewing the DOM and accessibility trees. All chromes now use the WebView
inspector model for those trees, thus this class is unused.
This allows Ladybird to be the default browser on macOS, and allows for
opening some file types (.html, .svg, .md, etc.) with Ladybird.
Note this currently only works in the GN build (and thus the Qt chrome).
The CMake build does not set up the Resources directory properly for
macOS to run the Ladybird app without $SERENITY_SOURCE_DIR set.
The default behavior of QPushButton is much closer to what we want from
a drop-down menu, as shown in the QPushButton::setMenu documentation:
https://doc.qt.io/qt-6/qpushbutton.html#setMenu
This also results in much less of a "squished" look than before.
The current size is too small to be able to read the new tab URL. Use
the `resize` API rather than setting a fixed-size as well, to allow the
user to resize the dialog themselves.
After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
This template app from Android Studio should hopefully be more fun to
work on than the Qt wrapped application we were using before. :^)
It currently builds the native code using gradle rules, and has a stub
WebViewImplementationNative class that will wrap a c++ class of the same
name that inhertis from WebView::ViewImplementation. Spawning helper
processes and creating proper views in Kotlin is next on the list.
These classes are used as-is in all chromes. Move them to LibWebView so
that non-Serenity chromes don't have to awkwardly reach into its headers
and sources.
This creates WebView::ConsoleClient to handle functionality that will be
common to the JS consoles of all Ladybird chromes. This will let each
chrome focus on just the UI.
Note that this includes the `console.group` functionality that only the
Serenity chrome previously had. This was a FIXME in the Qt chrome, and
it is implemented such that all chromes will receive this functionality
for free.
The old names sounded like awkward English to me, as they implied the
WebContent process is asking for information. In reality, WebContent is
*providing* the information.
