This API lets applications specify which configuration domains they
will be accessing throughout their lifetime. It works similarly in
spirit to the kernel's pledge().
You cannot pledge_domains() more than once, and once you have used it,
it's no longer possible to access any other configuration domain.
This is obviously just a first cut of this mechanism, and we may need
to tweak it further as we go.
It's not possible to connect to ConfigServer without having an event
loop available. This VERIFY makes it much easier to understand why
things are not working. :^)
This static bool getter can be used to VERIFY that an event loop exists,
in situations where one is expected.
This is helpful if the absence of an event loop would generate strange
and/or loud errors that don't immediately point to this as a cause.
ConfigServer is an IPC service that provides access to application
configuration and settings. The idea is to replace all uses of
Core::ConfigFile with IPC requests to ConfigServer.
This first cut of the API is pretty similar to Core::ConfigFile.
The old:
auto config = Core::ConfigFile::open_for_app("App");
auto value = config->read_entry("Group", "Key");
The new:
auto value = Config::read_string("App", "Group", "Key");
ConfigServer uses the ~/.config directory as its backing store
and all the files remain human-editable. :^)
Since there are no real users of these functions in Serenity's
userland and this is my third attempt at this... This time, the great
LibTest test suite will make sure that I do it right!
Calling sigprocmask() through the PLT requires setting the ebx register
to the address of the global offset table, otherwise chaos ensues. Also
the value of the ecx register was assumed to be preserved across that
function call despite the fact that it is caller-saved in the x86
calling convention.
This isn't 100% spec complaint, as it should use glyph_height()
depending on what the value of the writing-mode is, but we haven't
implemented it yet, so I think it'll be good enough for now.
This can be tested in https://wpt.live/css/css-values/ch-unit-008.html
Other css-unit tests fail as:
- 001 shows an issue related to a renderer (looks to me like you can't
pass a width and height property to a span -- adding `display: block`
to it passes the test),
- 002-004 and 009-012 use mentioned writing-mode,
- 016-017 loads custom fonts, which we also don't support (yet).
The more important thing here is to update the tree view
on 'Save As..', as we want to drop every connection from an old file.
Updating the tree view on current editor change is just a cool small
bonus. :^)
When property() previously would have returned an InitialStyleValue, we
now look up what the initial value would be, and return that instead.
We also intercep 'inherit', but inheritance is not implemented yet so we
just return nothing.
This does cause a regression on Acid2: The eyes no longer appear, and I
am not sure why. :^(
Since we have initial-value data in Properties.json already, it makes
sense to use that instead of needing to duplicate the same information
in ComputedValues.h
However, converting a StyleValue to the kind of types used in
InitialValues is non-trivial. So this may or may not actually be useful.
In order to use VirtualAddresses as compile time constants in the
AddressSanitizer implementation, we need to be able to use these
methods in constexpr functions / variable initializations.
The pattern of having Prekernel inherit all of the build flags of the
Kernel, and then disabling some flags by adding `-fno-<flag>` options
to then disable those options doesn't work in all scenarios. For example
the ASAN flag `-fasan-shadow-offset=<offset>` has no option to disable
it once it's been passed, so in a future change where this flag is added
we need to be able to disable it cleanly.
The cleaner way is to just allow the Prekernel CMake logic to filter out
the COMPILE_OPTIONS specified for that specific target. This allows us
to remove individual options without trashing all inherited options.
This bug was discovered via OSS fuzz, it's possible to fall through
to this assert with a char_size == 1, so we need to account for that
in the VERIFY(..).
Repro test case can be found in the OSS fuzz bug:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37296
We have seen cases where the map fails, but we return the region
to the caller, causing them to page fault later on when they touch
the region.
The fix is to always observe the return code of map/remap.
Instead of building the web DOM by hand, we now load an empty document
into an OutOfProcessWebView, and then append things to it by sending
little snippets of JavaScript to the host process. :^)
This patch adds OutOfProcessWebView::run_javascript(StringView).
This can be used by the OOPWV embedder to execute arbitrary JavaScript
in the top-level browsing context on the WebContent process side.
The IRC Client application made some sense while our main communication
hub was an IRC channel. Now that we've moved on, IRC is just a random
protocol with no particular relevance to this project.
This also has the benefit of removing one major client of the single-
process Web::InProcessWebView class.
