This solves a problem where checking whether a thread is an idle
thread may require iterating all processors if it is not the idle
thread of the current processor.
Previously, the method for computing the height of absolutely positioned
replaced elements only invoked the method for non-replaced elements.
That method is now implemented fully enough that it sometimes computed a
height of 0 for replaced elements. This implements section 10.6.5 rule 1
of the CSS spec to avoid that behavior.
The user's GID is already available via gid(), and it's not "extra", so
don't include it in extra_gids() again. Also rename the internally used
function from get_gids() to get_extra_gids() to make its purpose more
clear.
Previously we would return a 0xdeadc0de frame for every kernel frame
in the real kernel stack when an non super-user issued the request.
This isn't useful, and just produces visual clutter in tools which
attempt to symbolize stacks.
This ignores unhandled mouse clicks for the window buttons. Right now
right-clicking on the window buttons animates them as if some action
were to occur when the mouse button is released.
Recent changes in the button painting code made this unnecessary. For
the case of value() == max(), the scrubber button would overlap the
increment button.
Fixes#6838.
Add a Discord badge to the top of the README.md file. It will show
the number of online users in the Discord server. If clicked it will
redirect you to the invite page.
Most of the IPC that happens between clients and WindowServer when
creating and configuring windows can be asynchronous. This further
reduces the amount of ping-ponging played during application startup.
Creating a menu/menubar needs to be synchronous because we need the
ID from the response, but adding stuff *to* menus (and adding menus
to menubars, and menubars to windows) can all be asynchronous.
This dramatically reduces the amount of IPC ping-pong played by
each GUI application during startup.
I measured how long it takes TextEditor to enter the main event loop
and it's over 10% faster here. (Down from ~86ms to ~74ms)
This changes client methods so that they return the IPC response's
return value directly - instead of the response struct - for IPC
methods which only have a single return value.
This enables support for automatically generating client methods.
With this added the user gets code completion support for all
IPC methods which are available on a connection object.
When attempting to fix the dirent code I also changed
this to use strlcpy instead of the custom string copy
loop that was there before. Looking over strlcpy it
looked like it should work when using a non null terminated
string, I obviously misinterpreted the implementation
as it will read till it finds a null terminator.
Manually null terminate the string to address this.
Gunnar found this after he fixed UserspaceEmulator.
I reproduced it locally using his branch, and also
found the memory leak I had in the unit test for the
scandir that I added, so lets fix that as well.
Reported-by: Gunnar Beutner <gbeutner@serenityos.org>
This patches fixes a crash of the Userland/TextEditor where it would
crash when deleting a range spanning two lines. This was because the
TextEditor would delete the range and modify the cursor position
before clearing the selection. This would trigger a status bar update
with the invalid selection.
math.cpp: In function 'int64_t __moddi3(int64_t, int64_t)':
math.cpp:168:13: error: 'r' may be used uninitialized
[-Werror=maybe-uninitialized]
168 | return ((int64_t)r ^ s) - s; // negate if s == -1
| ^~~~~~~~~~
Adding -fno-semantic-interposition to the GCC command
line caused this new warning.
I don't see how output.data() could be uninitialized here. Also,
commenting out the ensure_capacity() call for the Vector
also gets rid of this warning.
Ordinarily this would force the compiler to not inline certain
symbols and call them via the PLT instead. To counteract this
I've also added -fno-semantic-interposition which disables
ELF symbol interposition. Our dynamic loader doesn't support
this anyway and we might even consider not implementing this
at all.
Even though this is a toolchain change this doesn't require
rebuilding the toolchain unless you're planning to build
for the x86_64 arch.
