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.
This implements a dialog that can be used to evaluate a JS expression
in the HackStudio's Debugger context. It also implements simple
C++ Variable <-> JS Value conversion, allowing for JS expressions
to read/write variables in the debugger scope.
Currently, C++ structs are mapped to JS objects by way of a JS proxy,
however this leads to issues when printing, so this will be changed
in a later commit.
In HackStudio's Debugger a custom GlobalObject is used to reflect
debugger variables into the JS scope by overriding GlobalObject's
get method. However, when throwing a custom error during that lookup
it was replaced with the generic "not found" js exception. This patch
makes it instead pass along the custom error.
This patch removes the IPC endpoint numbers that needed to be specified
in the IPC files. Since the string hash is a (hopefully) collision free
number that depends on the name of the endpoint, we now use that
instead. :^)
Additionally, endpoint magic is now treated as a u32, because endpoint
numbers were never negative anyway.
For cases where the endpoint number does have to be hardcoded (a current
case is LookupServer because the endpoint number must be known in LibC),
the syntax has been made more explicit to avoid confusing those
unfamiliar. To hardcode the endpoint magic, the following syntax is now
used:
endpoint EndpointName [magic=1234]
This patch implements a couple of enhancements to the synthesizer
engine:
* Each track has a volume control.
* The input and tooltips for all controls are improved.
* The noise channel is pitched, which allows for basic drum synthesis.
This patch implements Vim motions. The VimMotion class will accept
keycodes from the editing engine to build up a motion, and will
signal when a motion is complete via VimMotion::is_complete(). The
editing engine can then call VimMotion::get_range() to obtain a
TextRange object which can be used to perform operations on the text,
or VimMotion::get_position() to obtain a TextPosition which is the
new position of the cursor after the motion.
Currently, the following motions are supported:
- h/j/k/l, regular Vim line and character movements
- 0/^/$, start/end of line and start of non-blank
- w/e/b/ge, word-related movements
- W/E/B/gE, WORD (anything non-blank) versions of the above motions
- gg/G, document related movements
- t/f, to/find character
All motions except gg/G accept a number prefix to repeat the motion that
many times.
This patch updates insert, normal and visual modes to use this motion
system for movement.
Without a SONAME gcc will put the whole library path into executables
which link against these libraries:
$ readelf -d Root/usr/local/games/openttd
Dynamic section at offset 0xf0747c contains 32 entries:
Tag Type Name/Value
0x00000001 (NEEDED) [libgcc_s.so]
0x00000001 (NEEDED) [/serenity/Build/i686/Root/usr/local/lib/libpng.so]
0x00000001 (NEEDED) [/serenity/Build/i686/Root/usr/local/lib/libz.so]
0x00000001 (NEEDED) [/serenity/Build/i686/Root/usr/local/lib/liblzma.so]
0x00000001 (NEEDED) [libSDL2-2.0.so.1]
0x00000001 (NEEDED) [libicui18n.so.69]
0x00000001 (NEEDED) [libicuuc.so.69]
0x00000001 (NEEDED) [libicudata.so.69]
0x00000001 (NEEDED) [libpthread.so]
0x00000001 (NEEDED) [libm.so]
0x00000001 (NEEDED) [libc.so]
This causes the executable to fail because the dynamic linker
tries to find the library in the incorrect path.
This implements more of the dlfcn functionality. Most notably:
* It's now possible to dlopen() libraries which were already
loaded at program startup time. This does not cause those
libraries to be loaded twice.
* Errors are reported via dlerror() rather than by crashing
the program.
* Calls to the dl*() functions are thread-safe.