As the name of the Browser app is now titled Ladybird this was resulting in a
double up if installed fresh then rebooted (or likely after an upgrade). This
change corrects this by using the Ladybird title
We now create a WorkerAgent for the parent context, which is currently
only a Window. Note that Workers can have Workers per the spec.
The WorkerAgent spawns a WebWorker process to hold the actual
script execution of the Worker. This is modeled with the
DedicatedWorkerHost object in the WebWorker process.
A start_dedicated_worker IPC method in the WebWorker IPC creates the
WorkerHost object. Future different worker types may use different IPC
messages to create their WorkerHost instance.
This implementation cannot yet postMessage between the parent and the
child processes.
Co-Authored-By: Andreas Kling <kling@serenityos.org>
The entries in the QuickLaunchWidget are now saved properly. This means
that the format with which they are saved needed to be changed, since we
now also need to store the order of the entries. To do this, the entries
are now saved using the following value format: "<index>:<path>". When
loading, we simply parse this structure out and sort by the index,
before parsing the path into `QuickLaunchEntry`s.
Instead of managing a large list of tests to skip as we break aarch64,
simply don't run any userspace tests. We need to keep a smoke test going
so that we don't break aarch64 boot with new Kernel changes and new
drivers.
This is a sensible separation of concerns that mirrors the WindowServer
IPC split. On the one hand, there is the "normal" audio interface, used
for clients that play audio, which is the primary service of
AudioServer. On the other hand, there is the management interface,
which, like the WindowManager endpoint, provides higher-level control
over clients and the server itself.
The reasoning for this split are manifold, as mentioned we are mirroring
the WindowServer split. Another indication to the sensibility of the
split is that no single audio client used the APIs of both interfaces.
Also, useless audio queues are no longer created for managing clients
(since those don't even exist, just like there's no window backing
bitmap for window managing clients), eliminating any bugs that may occur
there as they have in the past.
Implementation-wise, we just move all the APIs and implementations from
the old AudioServer into the AudioManagerServer (and respective clients,
of course). There is one point of duplication, namely the hardware
sample rate. This will be fixed in combination with per-client sample
rate, eliminating client-side resampling and the related update bugs.
For now, we keep one legacy API to simplify the transition.
The new AudioManagerServer also gains a hardware sample rate change
callback to have exact symmetry on the main server parameters (getter,
setter, and callback).
This ensures that the RAM does not fill up with already processed
coredumps when many tests crash (as is the case on AArch64). We only
do this in self-test mode so as to avoid racing CrashDaemon.
Since LibFSAC requires a reified window before loading a font, it
makes sense to have a safe null state for the app.
This lets us stay alive after a failed file request on startup,
handle failure at any point during initialization, and claw back
memory from all our font RefPtrs.
A default startup font or none at all can now be set in FontEditor.ini
This allows it to read/write to the user's clipboard properly. Prior to
this, it would be writing to the Clipboard server running under the
window user, which doesn't impact other users (like anon).
Co-authored-by: Daniel Bertalan <dani@danielbertalan.dev>
This program has never lived up to its original idea, and has been
broken for years (property editing, etc). It's also unmaintained and
off-by-default since forever.
At this point, Inspector is more of a maintenance burden than a feature,
so this commit removes it from the system, along with the mechanism in
Core::EventLoop that enables it.
If we decide we want the feature again in the future, it can be
reimplemented better. :^)
This adds a checkbox to enable autoplay on all websites (disabled by
default) and a website list to enable autoplay on individual websites
(set to file:// URLs only by default).
We currently aren't parsing the last line of emoji-serenity.txt because
Core::Stream does not think the last line is readable. We should, of
course, fix Core::Stream. But keeping a trailing newline here is nice
anyways.
Let's put test files with the tests themselves, instead of a random user
directory. (But still copy them so they appear in the user directory
for convenience.)
This shouldn't be necessary but reproducing the odd corrupted profile
data from the nightly Azure runs is proving tricky locally. Hopefully
this will mitigate the issue.
The clipboard service hasn't been ported to user-based portals with
others services as it is needed at `GUI::Application` creation and thus
before the first login, as the `LoginServer` needs one.
This problem as been solved thanks to session-based portals, a clipboard
portal is now created at boot for the "login" session and another for
each "user" session.
With a user-based portal, the "login" portal would have needed to be
created for the `root` user, exposing us to security issues. It now, can
be owned by the `window` user.
This commit does three things atomically:
- switch over Core::Account+SystemServer+LoginServer to sid based socket
names.
- change socket names with %uid to %sid.
- add/update necessary pledges and unveils.
Userland: Switch over servers to sid based sockets
Userland: Properly pledge and unveil for sid based sockets
We have a high random failure rate on Shell tests, even with two of them
already manually disabled for being flaky. For now, let's skip them in
automated/CI testing so that "real" failures are more obvious.
Two of the tests have early-exits to disable them, which I wanted to
remove, but that makes `Meta/lint-shell-scripts.sh` very cross, so I'll
leave them.
Instead of manually updating emoji.txt whenever new emoji are added,
we use Unicode's emoji-test.txt to generate emoji.txt on each build,
including only the emojis that Serenity supports at that time.
By using emoji-test.txt, we can also include all forms of each emoji
(fully-qualified, minimally-qualified, and unqualified) which can be
helpful when double-checking how certain forms are handled.
