This really only affects headless-browser when it is linked with Qt. In
that case, it currently uses Qt networking by default and does not have
a flag to use RequestServer instead. Change the default to use RS so it
can undergo sanitized testing in CI.
The following command was used to clang-format these files:
clang-format-18 -i $(find . \
-not \( -path "./\.*" -prune \) \
-not \( -path "./Base/*" -prune \) \
-not \( -path "./Build/*" -prune \) \
-not \( -path "./Toolchain/*" -prune \) \
-not \( -path "./Ports/*" -prune \) \
-type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
There are a couple of weird cases where clang-format now thinks that a
pointer access in an initializer list, e.g. `m_member(ptr->foo)`, is a
lambda return statement, and it puts spaces around the `->`.
Previously the 'device independent pixels' (which consider scaling)
were used, and then scaling would be applied again when calculating the
screen width for CSS.
It previously resided in LibWebView to hide the details of launching a
singleton process. That functionality now lives in LibCore. By moving
this to Ladybird, we will be able to register the process with the task
manager.
This will be needed to collect statistics from processes that do not
have anything to do with LibWebView. The ProcessInfo structure must be
virtual to allow callers to add application-specific information.
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.
On macOS, it's not trivial to get a Mach task port for your children.
This implementation registers the chrome process as a well-known
service with launchd based on its pid, and lets each child process
send over a reference to its mach_task_self() back to the chrome.
We'll need this Mach task port right to get process statistics.
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.
On Serenity, it's not trivial to extract the peer pid from a socket that
is created by SystemServer and then passed to a forked service process.
This patch adds an API to let the WebContent process notify the UI
directly, which makes the WebContent process show up in the Serenity
port's TaskManagerWidget. It seems that we will need to do something of
this sort in order to properly gather metrics on macOS as well, due to
the way that self mach ports work.
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.
