This has been implemented in Qt for quite some time. This patch adds the
same feature to AppKit. This is needed to run many WPT subtests with the
AppKit chrome. This is also needed to handle window.open, target=_blank
link clicks, etc.
The main motivator here was noticing that --disable-sql-database did not
work with AppKit. Rather than re-implementing this there, move ownership
of these classes to WebView::Application, so that each UI does not need
to individually worry about it.
Currently, if we want to add a new e.g. WebContent command line option,
we have to add it to all of Qt, AppKit, and headless-browser. (Or worse,
we only add it to one of these, and we have feature disparity).
To prevent this, this moves command line flags to WebView::Application.
The flags are assigned to ChromeOptions and WebContentOptions structs.
Each chrome can still add its platform-specific options; for example,
the Qt chrome has a flag to enable Qt networking.
There should be no behavior change here, other than that AppKit will now
support command line flags that were previously only supported by Qt.
This adds a motion preference to the browser UI similar to the existing
ones for color scheme and contrast.
Both AppKit UI and Qt UI has this new preference.
The auto value is currently the same as NoPreference, follow-ups can
address wiring that up to the actual preference for the OS.
Now that the chrome process is a singleton on all platforms, we can
safely add a cache to the CookieJar to greatly speed up access. The way
this works is we read all cookies upfront from the database. As cookies
are updated by the web, we store a list of "dirty" cookies that need to
be flushed to the database. We do that synchronization every 30 seconds
and at shutdown.
There's plenty of room for improvement here, some of which is marked
with FIXMEs in the CookieJar.
Before these changes, in a SQL database populated with 300 cookies,
browsing to https://twinings.co.uk/ WebContent spent:
19,806ms waiting for a get-cookie response
505ms waiting for a set-cookie response
With these changes, it spends:
24ms waiting for a get-cookie response
15ms waiting for a set-cookie response
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.
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().
The setting for the search engine to use is currently ephemeral. Once we
have a settings dialog, we can implement this setting there, and persist
that setting.
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.
Currently, the only NSWindow type in the AppKit chrome is the Tab. Once
we have other window types (e.g. Inspector), commands which assume they
are used on a Tab will either crash or behave weirdly.
This changes the createNewTab: command to accept the tab from which the
new tab is created, rather than assuming that tab is the key window. So
if some JS on a page calls window.open() while a non-Tab window is key,
the new tab will be opened within the same tab group.
This also changes closeCurrentTab: to work on any key window. Regardless
of whether the key window is a Tab or some other window, pressing cmd+W
should just close that window.
This lets the user choose a color scheme which differs from the active
system theme. Upon changing the color scheme, the scheme is broadcast to
all active tabs, and will be used in new tabs.
This adds an alternative Ladybird chrome for macOS using the AppKit
framework. Just about everything needed for normal web browsing has
been implemented. This includes:
* Tabbed, scrollable navigation
* History navigation (back, forward, reload)
* Keyboard / mouse events
* Favicons
* Context menus
* Cookies
* Dialogs (alert, confirm, prompt)
* WebDriver support
This does not include debugging tools like the JavaScript console and
inspector, nor theme support.
The Qt chrome is still used by default. To use the AppKit chrome, set
the ENABLE_QT CMake option to OFF.
