Previous to this commit, if a `Window` wanted to set its width or height
greater than `INT16_MAX` (32768), both the application owning the Window
and the WindowServer would crash.
The root of this issue is that `size_would_overflow` check in `Bitmap`
has checks for `INT16_MAX`, and `Window.cpp:786` that is called by
`Gfx::Bitmap::create_with_anonymous_buffer` would get null back, then
causing a chain of events resulting in crashes.
Crashes can still occur but with `VERIFY` and `did_misbehave` the
causes of the crash can be more readily identified.
Use the configured desktop background color, if defined, otherwise
default to the current theme's background color. If a user chooses
a background color via "desktop settings", then this new color
will always be used.
Switching themes will delete the user-defined background color, so
the background color resets to the theme's defined color.
This replaces all occurrences of those functions with the newly
implemented functions URL::percent_encode() and URL::percent_decode().
The old functions will be removed in a further commit.
These dbgln's caused excessive load in the WebServer process,
accounting for ~67% of the processing time when serving a webpage
with a bunch of resources like serenityos.org/happy/2nd/.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
Just casting a void* to a T* and dereferencing it is not particularly
safe. Also UBSAN was complaining. Use memcpy into a default constructed
T instead and require that the T be trivially copyable.
Previously we'd only only send one DHCP request for network interfaces
which were up when DHCPClient started. If that packet was lost we'd
never send another request for those interfaces.
Also, if an interface were to appear after DHCPClient started (not
that that is possible at the moment) we wouldn't send requests for
that interface either.
Instead of using a low-level, proprietary API inside LibGfx, let's use
Core::AnonymousBuffer which already abstracts anon_fd and offers a
higher-level API too.
This functionality, while neat, isn't really something you need enabled
all the time. Let's make it opt-in instead. Pass MakeInspectable::Yes
to the Core::EventLoop constructor if you want your program to become
inspectable.
Changes to the system font settings are now persisted in /etc.
Note that you still need to restart the system for changes to fully
apply in all programs.
This patch adds a set_system_fonts() IPC API that takes the two main
font queries as parameters. We'll probably expand this with additional
queries when we figure out what they should be.
Note that changing the system fonts on a live system mostly takes
effect in newly launched programs. This is because GUI::Widget will
currently cache a pointer to the Gfx::FontDatabase::default_font()
when first constructed. This is something we'll have to fix somehow.
Also note that the settings are not yet persisted.
Instead of everybody getting their system fonts from Gfx::FontDatabase
(where it's all hardcoded), they now get it from WindowServer.
These are then plumbed into the usual Gfx::FontDatabase places so that
the old default_font() and default_fixed_width_font() APIs keep working.
Problem:
- `static` variables consume memory and sometimes are less
optimizable.
- `static const` variables can be `constexpr`, usually.
- `static` function-local variables require an initialization check
every time the function is run.
Solution:
- If a global `static` variable is only used in a single function then
move it into the function and make it non-`static` and `constexpr`.
- Make all global `static` variables `constexpr` instead of `const`.
- Change function-local `static const[expr]` variables to be just
`constexpr`.
Instead of doing a full IPC round-trip for the client and server to
greet each other upon connecting, the server now automatically sends
a "fast_greet" message when a client connects.
The client simply waits for that message to arrive before proceeding.
(Waiting is necessary since LibGUI relies on the palette information
included in the greeting.)
For compressed coredumps, CrashReporter's argv were in this order:
CrashReporter path --unlink
Core::ArgsParser doesn't like that at all and would immediately exit
from main(), causing the crash reporter to never display.
The recent patch to LexicalPath allowed relative paths like ../ to work
in requests to WebServer. This wasn't too dangerous because of unveil,
but let's still fix this :^)
This was only synchronous since WindowServer managed the ID allocation.
Doing this on the client side instead allows us to make create_menu()
an asynchronous IPC call, removing a bunch of IPC stalls during
application startup.
