Implement bookmark import/export in about:bookmarks using Netscape
bookmark HTML in JavaScript.
Import parsed items into BookmarkStore under an "Imported Bookmarks"
folder, and treat internal WebUI about: pages as potentially
trustworthy so SecureContext APIs are available there.
Passing the browser command line and executable path to every WebContent
process just in case we load about:version always felt a bit weird. We
now use the WebUI framework to load this information on demand.
This patch updates the about:version page to use the shared Ladybird
WebUI styling and present version, build, and runtime details in cards.
It also adds the Ladybird logo and a page title to about:processes,
without otherwise changing the process table behavior.
Route the existing Clear Browsing Data dialog through HistoryStore's
time-range deletion path as well. That makes the Settings action
remove visited pages from persisted history and from history-backed
address bar suggestions instead of only touching cache and site data.
Add a history checkbox to the dialog, thread its state through the
Settings WebUI message, and cover remove_entries_accessed_since() for
both transient and persisted stores in TestHistoryStore.
This page renders the bookmarks as a tree and hook context menu events
up to the UI's bookmarks bar context menus to allow editing bookmarks.
Users can also drag-and-drop bookmark items around.
Rather than rolling our own JavaScript to detect clicks outside of the
dialogs and close them we can set the closedby attribute to "any" which
will do the same thing.
This should also handle platform-specific user actions like pressing the
Escape key but this doesn't currently work so keep our JavaScript to
handle that and add a FIXME.
The tabless page with an ever-growing list of vertical cards was getting
a bit disorganized. This moves each section of the settings page to be
its own tab, with buttons to switch tabs. Some of this presented the
opportunity to migrate settings from popup dialogs to be directly in the
tab, such as the disk cache settings.
The global "restore defaults" button has also been removed. The more
settings we have, the less sense such a button makes sense. Individual
settings can have a reset option where it makes sense.
This adds a settings box to about:settings to allow users to limit the
disk cache size. This will override the default 5 GiB limit. We do not
automatically delete cache data if the new limit is suddenly less than
the used disk space; this will happen on the next request. This allows
multiple changes to the settings in a row without thrashing the cache.
In the future, we can add more toggles, such as disabling the disk
cache altogether.
The idea here was to use popovers, which natively support dismissal via
clicking outside the dialog and pressing the escape key. However, unlike
modals, popovers do not make the rest of the document inert. And there
isn't a handy way to achieve this. So while a popover is open, you could
interact with elements behind the dialog, which we don't want.
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.
