This adds a section to allow users to clear the HTTP disk cache and
cookies / local storage / session storage. There are a few options to
limit this action to a specific time range (e.g. "last hour"). The
user is informed how much disk space is being used currently, and how
much will be removed given the selected time range.
The idea is that in the future, we can add more settings here to auto-
delete data on exit, disable caching altogether, etc.
Global Privacy Control aims to be a replacement for Do Not Track. DNT
ended up not being a great solution, as it wasn't enforced by law. This
actually resulted in the DNT header serving as an extra fingerprinting
data point.
GPC is becoming enforced by law in USA states such as California and
Colorado. CA is further working on a bill which requires that browsers
implement such an opt-out preference signal (OOPS):
https://cppa.ca.gov/announcements/2025/20250911.html
This patch replaces DNT with GPC and hooks up the associated settings.
Currently, enabling search is a bit hokey. You have to click a checkbox
to get the search engines to show up, then you have to click a drop down
to select an engine. Let's go with a simpler approach; now you only have
to interact with the drop down.
The about:settings page has gotten beefy enough that it is a bit of a
paint to manage in a single HTML file. This patch breaks the settings
into several modules to make this page easier to mantain.
Modules have some nice benefits over classic scripts, such as enabling
strict mode by default, and allowing each module to function without
polluting the global object.
This allows the user to store custom search engines via about:settings.
Custom engines will be displayed below the builtin engines in the drop-
down to select the default engine.
A couple of edge cases here:
1. We currently reject a custom engine if one with the same name already
exists. In the future, we should allow editing custom engines.
2. If a custom engine which was the default engine is removed, we will
disable search rather than falling back to any other engine.
This implements a setting to change the languages provided to websites
from `navigator.language(s)` and the `Accept-Language` header. Whereas
the existing Qt settings dialog allows users to type their language of
choice, this setting allows users to select from a predefined list of
languages. They may choose any number of languages and their preferred
order.
This patch only implements the persisted settings and their UI. It does
not integrate the choses languages into the WebContent process.
The dialog classes here have specific names that will be used in another
dialog. This patch renames them to be more generic. And moves a border
style to not assume a dialog-footer element will exist.
This implements an autocomplete engine inside LibWebView, to replace the
engine currently used by Qt. Whereas Qt uses the Qt Network framework to
perform autocomplete requests, LibWebView uses RequestServer. This moves
downloading this untrusted data out of the browser process.
This patch only implements the persisted settings and their UI. It does
not integrate this engine into the browser UI.
This removes the old autoplay allowlist file in favor of the new site
setting. We still support the command-line flag to enable autoplay
globally, as this is needed for WPT.
The idea with the UI here is that it will serve as a generic component
for all site settings, such as autoplay, notifications, etc. When the
site settings dialog is opened, it is filled with the requested setting
data, and messages sent to the browser process are based on the setting.
This patch only implements the UI and persisted settings. It does not
apply autoplay changes to the WebContent process.
This adds a basic settings page to manage persistent Ladybird settings.
As a first pass, this exposes settings for the new tab page URL and the
default search engine.
The way the search engine option works is that once search is enabled,
the user must choose their default search engine; we do not apply any
default automatically. Search remains disabled until this is done.
There are a couple of improvements that we should make here:
* Settings changes are not broadcasted to all open about:settings pages.
So if two instances are open, and the user changes the search engine
in one instance, the other instance will have a stale UI.
* Adding an IPC per setting is going to get annoying. It would be nice
if we can come up with a smaller set of IPCs to send only the relevant
changed settings.
In order to maintain a consistent look and feel between internal about:
pages going forward, let's use a central CSS file to define Ladybird
colors and some common form control styles.
The intent is that this will replace the separate Task Manager window.
This will allow us to more easily add features such as actual process
management, better rendering of the process table, etc. Included in this
page is the ability to sort table rows.
This also lays the ground work for more internal `about` pages, such as
about:config.
This commit:
- Prevents path traversal via the about: scheme
- Prevents loading about:inspector
- Requires about: URIs to be opaque paths
- Prevents crashes with invalid percent encoded paths
Remember the query, so that if you're filtering for "color" on the
computed style tab, and switch to the resolved style tab, it's filtered
for "color" too.
This means we also can save looking up the filter text when a new node
is inspected.
If you have a search filter and then click on a different node, this now
applies the filter to the new node's properties, instead of showing all
of them.
The usage of color-scheme was introduced in commit:
ce5cd012b9
This reverts the Inspector to use self-selected colors, as the default
color-scheme colors do not look great in this window.
These used to serve as tests before we had proper testing infrastructure
set up. Now, they just sit forgotten about, gathering dust. Let's remove
them.
