When a new Window instance is added to the WindowManager, it does not
yet have an updated value for `m_frame->rect()` and we're not checking
if there is a new candidate for the hovered window, which we need to do
since the mouse cursor might hover above the newly opened window.
This fixes both issues: as soon as a Window frame's rect is changed,
ask the WindowManager to reevaluate its hovered window. This takes care
of newly opened windows _and_ windows that are programmatically changed
in size.
This works because when a Window becomes hovered, the WindowManager
sends out an enter event. This event in turn triggers the Window to
evaluate the cursor type under the mouse position and to update it when
necessary.
Fixes#4809.
LibAudio's WavLoader plugin for loading WAV files now supports loading
audio files with 32-bit float or 64-bit float samples.
By supporting these new non-int sample formats, Audio::Buffer now stores
the sample format (out of a list of supported formats) instead of the
raw bit depth. (The bit depth is easily calculated with
pcm_bits_per_sample)
The overall design is the same, but we change a few things,
like decreasing the amount of blocking forever loops. The goal
is to ensure the kernel won't hang forever when dealing with
buggy hardware.
Also, we reset the channel when initializing it, just in case the
hardware was in bad state before we start use it.
The last IP address in an IPv4 subnet is considered the directed
broadcast address, e.g. for 192.168.3.0/24 the directed broadcast
address is 192.168.3.255. We need to consider this address as
belonging to the interface.
Here's an example with this fix applied, SerenityOS has 192.168.3.190:
[gunnar@nyx ~]$ ping -b 192.168.3.255
WARNING: pinging broadcast address
PING 192.168.3.255 (192.168.3.255) 56(84) bytes of data.
64 bytes from 192.168.3.175: icmp_seq=1 ttl=64 time=0.950 ms
64 bytes from 192.168.3.188: icmp_seq=1 ttl=64 time=2.33 ms
64 bytes from 192.168.3.46: icmp_seq=1 ttl=64 time=2.77 ms
64 bytes from 192.168.3.41: icmp_seq=1 ttl=64 time=4.15 ms
64 bytes from 192.168.3.190: icmp_seq=1 ttl=64 time=29.4 ms
64 bytes from 192.168.3.42: icmp_seq=1 ttl=64 time=30.8 ms
64 bytes from 192.168.3.55: icmp_seq=1 ttl=64 time=31.0 ms
64 bytes from 192.168.3.30: icmp_seq=1 ttl=64 time=33.2 ms
64 bytes from 192.168.3.31: icmp_seq=1 ttl=64 time=33.2 ms
64 bytes from 192.168.3.173: icmp_seq=1 ttl=64 time=41.7 ms
64 bytes from 192.168.3.43: icmp_seq=1 ttl=64 time=47.7 ms
^C
--- 192.168.3.255 ping statistics ---
1 packets transmitted, 1 received, +10 duplicates, 0% packet loss,
time 0ms, rtt min/avg/max/mdev = 0.950/23.376/47.676/16.539 ms
[gunnar@nyx ~]$
This turns the perfcore format into more a log than it was before,
which lets us properly log process, thread and region
creation/destruction. This also makes it unnecessary to dump the
process' regions every time it is scheduled like we did before.
Incidentally this also fixes 'profile -c' because we previously ended
up incorrectly dumping the parent's region map into the profile data.
Log-based mmap support enables profiling shared libraries which
are loaded at runtime, e.g. via dlopen().
This enables profiling both the parent and child process for
programs which use execve(). Previously we'd discard the profiling
data for the old process.
The Profiler tool has been updated to not treat thread IDs as
process IDs anymore. This enables support for processes with more
than one thread. Also, there's a new widget to filter which
process should be displayed.
If you start a URL with a '?' character, the Browser will use the
user-selected search engine (none by default).
For now, there are several engines hardcoded and there is no support
for custom search engines.
- Reorganized some variables (alphabetically and based on their function) so that the new ones don't stick out.
- See: https://github.com/SerenityOS/serenity/issues/6068
Co-authored-by: Linus Groh <mail@linusgroh.de>
We don't support hashes from external files (anymore), downloading
another file for integrity validation is pointless. As as result, these
two ports would refuse to build as their hashes were missing.
Fixes#6645.
This is how it's stored internally - even though we still only construct
from i32. I had the compiler yell at me while trying something with this
and didn't want to add yet another cast, so let's quickly fix this.
The current ProtocolServer was really only used for requests, and with
the recent introduction of the WebSocket service, long-lasting
connections with another server are not part of it. To better reflect
this, this commit renames it to RequestServer.
This commit also changes the existing 'protocol' portal to 'request',
the existing 'protocol' user and group to 'request', and most mentions
of the 'download' aspect of the request to 'request' when relevant, to
make everything consistent across the system.
Note that LibProtocol still exists as-is, but the more generic Client
class and the more specific Download class have both been renamed to a
more accurate RequestClient and Request to match the new names.
This commit only change names, not behaviors.
The WebSocket bindings match the original specification from the
WHATWG living standard, but do not match the later update of the
standard that involves FETCH. The FETCH update will be handled later
since the changes would also affect XMLHttpRequest.
The WebSocket service isolates communication with a WebSocket to its
own isolated process. Similar to other isolating services, it has its
own user and group.
This patch adds a custom JS Object type that will convert written
properties to their C++ equivalents, reflecting JS writes back
to the debugging session. This is better than a simple proxy because
printing this custom object works as expected because properties
still exist on the object as existing handlers expect.
