These changes are arbitrarily divided into multiple commits to make it
easier to find potentially introduced bugs with git bisect.Everything:
The modifications in this commit were automatically made using the
following command:
find . -name '*.cpp' -exec sed -i -E 's/dbg\(\) << ("[^"{]*");/dbgln\(\1\);/' {} \;
Clients of LaunchServer can now provide a list of allowed handlers,
optionally with a specific set of URLs. The list can be sealed to
prevent future additions to it.
If LaunchServer receives a request to open something not on the allowed
handlers list, it will disconnect the client immediately.
The main idea here is to allow otherwise restricted programs to launch
specific things, e.g "Help" to open their manual, or "Browser" to load
the SerenityOS home page. :^)
This was mentioned in #4574, and the more I think about it the more it
feels just right - let's move it there! :^)
Having to link LaunchServer against LibGUI explicitly should've been
telling enough...
Browser supports very few protocols (http, https, gemini, file) at the
moment, so there's no point in using it as a catch-all and default
protocol handler. I added an explicit association for gemini to
/bin/Browser instead.
This stops Desktop::Launcher::open() from reporting success for any URL,
which really isn't the case (Browser shows an error page...).
Problem:
- `(void)` simply casts the expression to void. This is understood to
indicate that it is ignored, but this is really a compiler trick to
get the compiler to not generate a warning.
Solution:
- Use the `[[maybe_unused]]` attribute to indicate the value is unused.
Note:
- Functions taking a `(void)` argument list have also been changed to
`()` because this is not needed and shows up in the same grep
command.
This patch introduces IPC::Connection which becomes the new base class
of ClientConnection and ServerConnection. Most of the functionality
has been hoisted up to the base class since almost all of it is useful
on both sides.
This gives us the ability to send synchronous messages in both
directions, which is needed for the WebContent server process.
Unlike other servers, WebContent does not mind blocking on a response
from its client.
By adding a special LauncherType::Application we can still
get meta data for the application, but also know that we should
consider executing that binary as the default action. LaunchServer
will not do this for us, as it should probably not be allowed to
run arbitrary binaries that haven't been registered as handlers.
And move canonicalized_path() to a static method on LexicalPath.
This is to make it clear that FileSystemPath/canonicalized_path() only
perform *lexical* canonicalization.
Adds metadata about apps for what file types and protocols they can
handle, then consumes that in the LaunchServer. The LaunchServer can
then use that to offer multiple options for what apps can open a given
URL. Callers can then pass back the handler name to the LaunchServer to
use an alternate app :)
Step one of moving DesktopServices::open handling out of process. This
makes it easier to do things like read in associations for which program
opens which files or protocols. This gives users the ability to modify
the associations without having to rebuild :^)
