This effectively makes us send a "mouse move" event to windows when they
become active, even if the mouse didn't actually move. By doing this, we
trigger hover/tooltip/etc logic immediately, instead of doing it on the
next 1px mouse movement.
It's a small detail but my goodness does it feel better this way. :^)
To ensure everything works as expected, a unit test was added with
multiple scenarios.
This binary has to have the SetUID flag, and we also bind-mount the
/usr/Tests directory to allow running of SetUID binaries.
This small change simplifies the function a bit but also fixes a problem
with it.
Let's take an example to see this:
Let's say we have a reserved range between 0xe0000 to 0xfffff (EBDA),
then we want to map from the memory device (/dev/mem) the entire
EBDA to a program. If a program tries to map more than 131072 bytes,
the current logic will work - the start address is 0xe0000, and ofcourse
it's below the limit, hence it passes the first two restrictions.
Then, the third if statement will fail if we try to mmap more than
the said allowed bytes.
However, let's take another scenario, where we try to mmap from
0xf0000 - but we try to mmap less than 131072 - but more than 65536.
In such case, we again pass the first two if statements, but the third
one is passed two, because it doesn't take into account the offseted
address from the start of the reserved range (0xe0000). In such case,
a user can easily mmap 65535 bytes above 0x100000. This might
seem negligible. However, it's still a severe bug that can theoretically
be exploited into a info leak or tampering with important kernel
structures.
Showing the selection in non-focused text editors was not really useful,
since refocusing the widget would clear or change the selection
immediately anyway.
Note that TextEditors in inactive windows can still be the focused
widget within that window, and will still be painted with an "inactive"
looking selection.
The FilePicker has implemented its common locations tray as a composite
widget built from a GUI::Frame with a bunch of GUI::Button inside it.
The problem with that is that it creates a long and annoying chain of
keyboard-focusable widgets.
This patch adds GUI::Tray, which is a dedicated single widget that
implements the same UI element, but without child widgets.
Toolbar buttons are meant for quick mouse access to common actions,
while quick keyboard access is normally achieved via keyboard shortcuts
and underlined menu items.
This makes interfaces with many toolbar buttons (e.g GUI::FilePicker)
a lot nicer to navigate via keyboard.
Storing assigning a string literal to a String object just to pass it to
a function expecting a StringView is wasteful. Let's just not do that.
For consistency's sake, this commit changes all of the other invocations
to use StringView literals, too.
Creating a String object from the formatted data is unnecessary, as it
immediately gets turned into a StringView anyways.
With this change, we will no longer allocate on the heap when printing
`VirtualAddress`, `VirtualRange` and `InodeIdentifier` objects, which is
a step towards stronger OOM hardening.
Forcing the formatting to go through `Formatter<FormatString>` is
completely unnecessary, increases code size, performs a String
allocation and prevents us from using the formatting options available
on that type.
This commit also removes explicit formatters from
`BlockBasedFileSystem::BlockIndex` and `Kernel::InodeIndex`, as those
are already covered by the blanket implementation for all
`DistinctNumeric` types.
Previously, only `manual` installs would register dependencies of an
installed port package. Since in the future we might want to check all
dependents, not only those for manually installed packages, we should
take care to register dependencies for `auto` installs as well.
Additionally, this surpresses some unnecessary verbose output from the
package management and fixes warnings when the package DB directory did
not yet exist.
GNU statement expressions fit the definition of IfAbruptRejectPromise
rather nicely, where we need to reject the failed promise (and return
the failed promise itself) on failure, and otherwise store a value on
success.
This is a bit ugly because, rather than simply wrapping the invocation
to GetPromiseResolve with TRY(), we have to invoke the promise's reject
method with any error. But this will be a bit cleaner in a subsequent
commit to change how IfAbruptRejectPromise is invoked.
