Previously, we used `on_load_finish` to determine when the text test
was completed. This method did not allow testing of async functions
because there was no way to indicate that the runner should wait for
the async call to end.
This change introduces a function in the `internals` object that is
intended to be called when the text test execution is completed. The
text test runner will now ignore `on_load_finish` which means a test
will timeout if this new function is never called.
`test(f)` function in `include.js` has been modified to automatically
terminate a test once `load` event is fired on `window`.
new `asyncTest(f)` function has been introduces. `f` receives function
that will terminate a test as a first argument.
Every test is expected to call either `test()` or `asyncTest()` to
complete. If not, it will remain hanging until a timeout occurs.
This attempts to load the URL of the first `<link rel="match" href=""/>`
it finds. If that tag is missing, we load an error page to make sure
the ref-test fails. (And to provide some feedback if someone looks at
the screenshot somehow.) Wrong URLs will instead end up loading the
default 404 error page.
Userspace initially didn't have any sort of mechanism to handle
device hotplug (either removing or inserting a device).
This meant that after a short term of scanning all known devices, by
fetching device events (DeviceEvent packets) from /dev/devctl, we
basically never try to read it again after SystemServer initialization
code.
To accommodate hotplug needs, we change SystemServer by ensuring it will
generate a known set of device nodes at their location during the its
main initialization code. This includes devices like /dev/mem, /dev/zero
and /dev/full, etc.
The actual responsible userspace program to handle hotplug events is a
new userspace program called DeviceMapper, with following key points:
- Its current task is to to constantly read the /dev/devctl device node.
Because we already created generic devices, we only handle devices
that are dynamically-generated in nature, like storage devices, audio
channels, etc.
- Since dynamically-generated device nodes could have an infinite minor
numbers, but major numbers are decoded to a device type, we create an
internal registry based on two structures - DeviceNodeFamily, and
RegisteredDeviceNode. DeviceNodeFamily objects are attached in the
main logic code, when handling a DeviceEvent device insertion packet.
A DeviceNodeFamily object has an internal HashTable to hold objects of
RegisteredDeviceNode class.
- Because some device nodes could still share the same major number (TTY
and serial TTY devices), we have two modes of allocation - limited
allocation (so a range is defined for a major number), or infinite
range. Therefore, two (or more) separate DeviceNodeFamily objects can
can exist albeit sharing the same major number, but they are required
to allocate from a different minor numbers' range to ensure there are
no collisions.
- As for KCOV, we handle this device differently. In case the user
compiled the kernel with such support - this happens to be a singular
device node that we usually don't need, so it's dynamically-generated
too, and because it has only one instance, we don't register it in our
internal registry to not make it complicated needlessly.
The Kernel code is modified to allow proper blocking in case of no
events in the DeviceControlDevice class, because otherwise we will need
to poll periodically the device to check if a new event is available,
which would waste CPU time for no good reason.
This change ensures that code in the Service class doesn't try to check
the g_system_mode variable, but instead is asked on whether it supports
a given system mode string value.
Also, don't assume that we should create sockets for any new Service
instance, but instead do that only if the Service should run in the
current system mode.
Just a small cleanup to ensure we can get these pieces of code out to
other files and still have the main.cpp file organized.
The populate_devtmpfs_char_devices_based_on_sysfs() method is removed
because we can simply create the /dev/devctl device node without looking
at the SysFS. This assumed-to-exist device node will be used later on in
an event loop to handle hotplug events.
Before page_did_create_main_document() only initialized ConsoleClient
for top-level browsing context which means that nested browsing context
could not print into the console.
With this change, ConsoleClient is initialized for documents created
for nested browsing context too. One ConsoleClient is shared between
all browsing contexts within the same page.
The Hurd has sin_len, just like the BSDs.
This happened to hit a clang-format bug, and we have been advised
to disable clang-format for this block of code for now.
The behavior of the Serenity `PlaybackStream` implementation should
match the `AudioCodecPluginSerenity` class removed by this commit. Any
inconsistencies should be fixable without needing feature additions to
the underlying implementation.
The name for this directory is a bit awkward. Also, the distinction of
constant information is not really valuable as I thought it would be, so
let's bring that information back into the /sys/kernel directory.
The name "variables" is a bit awkward and what the directory entries are
really about is kernel configuration so let's make it clear with the new
name.
On Serenity and on my Linux machine, we have a 1:1 CSS-to-device pixel
ratio. On macOS, we have a 2:1 ratio. This did not affect the Qt chrome,
because we are ignoring this position and placing the context menu at
the globally-accessible mouse position. The AppKit chrome will be using
this position, though.
This might be what caused the issue worked around by commit 8177ecb.
Having all 4 of these methods together makes it more immediately obvious
that the 2 moved here are not correct (we are not converting the CSS
pixel point to a device pixel point).
Stop worrying about tiny OOMs. Work towards #20449.
While going through these, I also changed the function signature in many
places where returning ThrowCompletionOr<T> is no longer necessary.
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.
This patch checks for visible items to determine the menu height. Now
the last visible item is used to determine the height of the menu.
Before this patch that menu height could be wrong e.g. if the last item
was not visible.
