Instead of relying on AK_OS_LINUX, actually use the more accurate
HAS_ACCELERATED_GRAPHICS define to figure out if we should try to use
the generic LibAccelGfx GPU painter.
This modification introduces a new layer to the painting process. The
stacking context traversal no longer immediately calls the
Gfx::Painter methods. Instead, it writes serialized painting commands
into newly introduced RecordingPainter. Created list of commands is
executed later to produce resulting bitmap.
Producing painting command list will make it easier to add new
optimizations:
- It's simpler to check if the painting result is not visible in the
viewport at the command level rather than during stacking context
traversal.
- Run painting in a separate thread. The painting thread can process
serialized painting commands, while the main thread can work on the
next paintable tree and safely invalidate the previous one.
- As we consider GPU-accelerated painting support, it would be easier
to back each painting command rather than constructing an alternative
for the entire Gfx::Painter API.
This commit removes DeprecatedString's "null" state, and replaces all
its users with one of the following:
- A normal, empty DeprecatedString
- Optional<DeprecatedString>
Note that null states of DeprecatedFlyString/StringView/etc are *not*
affected by this commit. However, DeprecatedString::empty() is now
considered equal to a null StringView.
Replaces `set_tooltip_deprecated(string);` with
`set_tooltip(MUST(String::from_deprecated_string(string)));`
purely to get rid of the deprecated function in the following commit.
Renaming the DeprecatedString version of this function to
deprecated_tag_name. A FlyString is used here as we often need to
perform equality checks here, and the HTMLParser already has tag_name as
a FlyString.
Remove a FIXME while we're at it - we were already following the spec
there, and we still are :^)
Renaming the DeprecatedString version of this function to
Element::get_deprecated_attribute.
While performing this rename, port over functions where it is trivial to
do so to the Optional<String> version of this function.
The following commit will port MIME types to String. Traits<String>
- used in Vector::contains_slow - can't compare String type with char*,
so we need to use StringView instead.
This commit introduces 3 things:
- Support for the color type in HTMLInputElement itself
- A mechanism for handling non event loop blocking dialogs in Page
- The associated plumbing up to ViewImplementation
Frontends may add support for the color picker with the
ViewImplementation.on_request_color_picker function
These functions are deferring to NamedNodeMap::get_attribute which
already takes a StringView. This changes also leads to finding some
places which were passing though a const char* instead of an entry from
Attribute names. Fix that where applicable, and switch to has_attribute
in some of those places instead of deprecated_attribute where
equivalent.
Ideally this should be taking a 'FlyString const&', but to continue
porting away from DeprecatedString, just leave a FIXME for now.
Previously, trying to access a non-readable file would cause a
connection reset in the browser; trying to access a non-executable
directory would show a completely empty directory listing.
After moving to navigables, we started reusing the code that populates
session history entries with the srcdoc attribute value from iframes
in `Page::load_html()` for loading HTML.
This change addresses a crash in `determine_the_origin` which occurred
because this method expected the URL to be `about:srcdoc` if we also
provided HTML content (previously, it was the URL passed along with the
HTML content into `load_html()`).
Fixes regression introduced in b4fe118dff
The `WebContentConsoleClient` needs to be created not just once, but
for every new document. Although the JS Console window allows
communication only with the active document associated with the
top-level browsing context, we still need a console client for each
iframe's document to ensure their console logs are printed.
In the future, we might consider adding the ability to switch which
document the JS Console window communicates with.
Fixes https://github.com/SerenityOS/serenity/issues/21117
The Kernel/API directory in general shouldn't include userspace code,
but structure definitions that both are shared between the Kernel and
userspace.
All users of the ioctl API obviously use LibC so LibC is the most common
and shared library for the affected programs.
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.
