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.
The logic for `EventLoopImplementationQt::pump()` caused calls to
`EventLoop::pump(PumpMode::DontWaitForEvents)` to not consume events
posted to the Qt event queue. This caused the window to be unresponsive
even when polling the event loop, if waiting was not desired.
If a URL is not valid we try navigating to https:// + the url. It's
better to ask AK::Url if it thinks the url is valid than put a big list
of prefixes here, with this obscure protocols like Gemini are now
recognised and with `--enable-lagom-networking` can be viewed in
Ladybird (thanks to #2218).
Now that all the classes for Ladybird are in the Ladybird namespace, we
don't need them named as Ladybird::FooBarLadybird. For the Qt-specific
classes, we can tack on a Qt at the end for clarity, but FontPlugin and
ImageCodecPlugin no longer have anything to do with Qt.
We were super inconsistent about this, with most "new" classes living in
the Ladybird namespace, while "old" ones were in the global namespace,
or even sitting in the Browser namespace.
Ladybird's RequestServer needs to depend on its generated IPC header
files to ensure they are generated before RequestServer is compiled,
which we currently bundle into LibWebView.
LibTLS still can't access many parts of the web, so let's hide this
behind a flag (with all the plumbing that entails).
Hopefully this can encourage folks to improve LibTLS's algorithm support
:^).
