Storing the backup bitmap is the same across Browser and Ladybird. Just
peform that work in LibWebView, and handle only the implementation-
specific nuances within the browsers.
This also sets the default callback to do what every non-Serenity
browser is doing, rather than copy-pasting this callback into every
implementation. The callback is still available for any platform which
might want to override the default behavior. For example, OOPWV now
overrides this callback to use FileSystemAccessClient.
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.
By running ctest -C Integration -R WPT, you can run WPT. Adding just
-C Integration will run all other tests *and* the WPT test.
Also add support for ./Meta/serenity.sh test lagom WPT to serenity.sh
The error.html page now uses the resource_directory_url this
variable contains the relative path to /Base/res/ on the host
system as a file:// url. This is needed for future pages to load
resource files like icons. For the error.html page this was not
really needed because it lies over this own URL in FrameLoader.cpp.
Non-Qt chromes will want to use the same Info.plist and bundle info as
the Qt chrome. This patch puts the CMake setup for the bundle into a
function that non-Qt chromes may call in their CMakeLists.txt. The Qt
chrome calls it automatically.
This will allow us to bring the WebContent process into non-Qt macOS
chromes. This branch is only reached when creating an <audio> element,
so while the chrome is heavily under development, we can just avoid
these elements.
We were still missing the resources and the libraries inside the actual
bundle directory. Do it at install time to not make a mess of all the
rules. The gn build lists all the libraries in a massive list, which
is quite a pain. We can over-copy a few libraries like this to make the
install script a bit easier to follow.
We weren't installing a lot of generated sources for the top level Lagom
build or for LibWeb, making it impossible to use LibWeb from a
find_package. ...And also Kernel/API/KeyCode.h, which is included by
no less than 8 different files in Userland/Libraries. We also weren't
installing any Ladybird header files.
We already do this for headless-browser. There's no need to open any URL
other than about:blank when starting a WebDriver session. We should also
do this from WebDriver code, rather than in special logic in Browser's
main.cpp.
The issue noted in the removed comment no longer seems to apply. The URL
loaded here is triggered before WebDriver even issues the POST /session
command.
When we launch Ladybird, we currently:
1. Create a BrowserWindow, whose constructor navigates to the configured
new tab page URL.
2. Then navigate to either "about:blank" or whatever URL is provided via
the command line.
This patch removes step 2 and forwards the URL from the command line (if
any) to BrowserWindow. BrowserWindow's constructor then either navigates
to that URL or the new tab page URL.
Currently, if the JS console is open and tied to the last opened tab in
the browser window, it will prevent the main process from exiting when
the last tab is closed. This change explicitly closes that tab before
closing the window (if it's the last tab), allowing Qt to delete the
Tab object.
This will help a lot with developing chromes for different UI frameworks
where we can see which helper classes and processes are really using Qt
vs just using it to get at helper data.
As a bonus, remove Qt dependency from WebDriver.
With the CMake build, the ladybird binary ends up in
$build/bin/ladybird.app/Contents/MacOS. Which is a bit unfortunate for
a few reasons, but the main one is that --enable-lagom-networking
doesn't work with ./Meta/serenity.sh run lagom ladybird.
Let's copy the file to the expected location. There's very likely better
solutions we can use in the future.
This object is available as `window.internals` (or just `internals`) and
is only accessible while running in "test mode".
This first version only has one API: gc(), which triggers a garbage
collection immediately.
In the future, we can add more APIs here to help us test parts of the
engine that are hard or impossible to reach via public web APIs.
The Qt docs are not that clear, but to get the number of steps the
wheel was scrolled you divide by 120 (which when multiplied by
wheelScrollLines() gives the scroll offset).
Documentation says that pixelDelta() is not reliable across platforms
so always using angleDelta() should produce more predictable scrolling
behaviour.
Rather than directing mouse wheel events to the QAbstractScrollArea,
send them to the WebContent process, allowing it to determine if they
should be consumed by the element or used for page scrolling.
The implementation of this plugin is meant to eventually replace all
current audio plugins in Ladybird. The benefits over the current Qt-
based audio playback plugin in Ladybird are:
- Low latency: With direct access to PulseAudio, we can ask for a
specific latency to output to allow minimal delay when pausing or
seeking a stream.
- Accurate timestamps: The Qt audio playback API does not expose audio
time properly. When we have access directly to PulseAudio APIs, we can
enable their timing interpolation to get an accurate monotonically-
increasing timestamp of the playing audio.
- Resiliency: With more control over how the underlying audio API is
called, we have the power to fix most bugs we might encounter. The
PulseAudio wrappers already avoid some bugs that occur with QAudioSink
when running through WSLg.
Previously, a QTimer was used to start processing of our event queue in
the main Qt event loop. Unfortunately, QTimers are not thread-safe, and
disallow starting of a timer from a different thread than it was
created in.
Instead, use a dummy QObject to post a custom QEvent to the main loop
from whatever thread we like, and process our event queue when it is
received by our dummy object.
