When a snap is launched from its non-dbus-activable desktop file we may
still need to use the portal to pass the URIs to the program, so that it
can access to them even if confined.
In fact most snaps are not dbus-activable, but they rely on the classic
desktop file activation.
Snap applications like flatpak apps may need to use the portals to open
files, so use the same logic that we have for flatpaks but using the
snap ID that matches portal expectations
We were checking the results of opening an sandboxed application, but
never if the open was actually invoked.
So if another desktop file was used in tests, we were never getting any
failure, at least not related to the lack of a file being opened
As per commit 0144feb41 the activate action paramter may pack multiple
values but while the behavior was checked we did not check the content
of the values we were receiving in the action callback.
So, also ensure that the variant values we receive are matching the
expectations.
Instead of guessing the portal file name by using the original file name
let's just inspect the portal document ID directory and get the actual
file name
In order to properly test the document portal, let's also create some
dummy files that are named after the FDs we receive and using the
document-id path as the real portal does
When an URI to a symlink is added to the portal, we open it and we send
the FD (of the target) to the portal. This one has no clue about the original
symlink and so it mounts a file that is named like the target.
g_document_portal_add_documents(), however returns a path that contains
the original name and that one is what is sent to the applications when
used via GDesktopAppInfo.
Basically, this is the situation:
- /tmp/symlink -> /tmp/target
- An application is launched to open file:/tmp/symlink
- The portal creates file:/$XDG_RUNTIME_DIR/doc/ID/target
- Gio converts the path to file:/$XDG_RUNTIME_DIR/doc/ID/symlink
Now, since we can't just pass the symlink to the portal without also
changing the logic there, it's just better to do the conversion ourself,
and so, we use the already-opened fd to figure out the real path of the
opened file, and we return a document file URI that uses the target
basename instead
The RFC9110 explanation of HTTP ETags is far superior to
the disjoint ramblings found in (now-obsoleted) RFC2616,
and serves as a much better reference for comparison
with GFile entiity tags. Also, link directly to relevant section.
This commit has the potential to close a thousand Coverity issues.
On generated code from gdbus-codegen, Coverity typically warns on
skeleton->priv->changed_properties_idle_source happening outside
the skeleketon->priv->lock during finalize(), while it's protected
by this mutex in other parts.
Presumably if the object is in finalization, there should be no
other threads poking at it, so the code is actually safe for the
intended use and the warning moot.
To address this, change gdbus-codegen to prefer g_clear_pointer()
with glib >= 2.38 (should be most often the case nowadays) so this
access is reserved to a single line of code, and mark this line of
code with a Coverity code annotation in order to suppress the
warning.
If the build/test machine is slow, heavily-loaded or otherwise
inconvenienced, it might take a few seconds for the signal to be sent
by the subprocess, received by the message bus, re-broadcasted by the
message bus and received by the test code. Wait a few more seconds
before giving up.
If this test is successful, increasing this timeout will not slow it
down: we stop waiting for the signal as soon as we receive it. This will
only make any difference if the test would have failed.
Signed-off-by: Simon McVittie <smcv@debian.org>
We have two things happening in parallel:
1. The GDBus worker thread writes out an AddMatch call to the socket,
the message bus reads that method call from the other end of the
socket, and the message bus responds by adding the match rule
for the signal subscription
2. The main thread forks, and the child execs
gdbus-connection-flush-helper, which sends the signal that we are
expecting; the message bus receives that signal, and broadcasts it
to subscribers, if any
Normally (1.) wins the race because exec'ing a child process is more
time-consuming than IPC, and the test passes.
However, it is possible for (2.) to win the race. If so, we will never
receive the expected signal (because it was received by the message bus
before the AddMatch() method call, so at the time it was received, the
test was not yet a subscriber); the test waits until the timeout and
then gives up, and the test fails.
For whatever reason, Debian's s390x buildd seems to be reliably failing
this test since this week, having previously passed. I don't know what
changed. I can (very rarely) reproduce the race condition described
above on a developer-accessible s390x machine by repeatedly running the
/gdbus/connection/flush test in a loop.
Bug-Debian: https://bugs.debian.org/1115617
Signed-off-by: Simon McVittie <smcv@debian.org>
With these adjustments, building with clang leads to no warnings:
- The "{ NULL }" statement could be replaced with "{ 0 }" to satisfy
clang, but this way it's explicitly filling all fields
- Even though "i" is not read with these g_array_binary_search calls,
it rightfully should be set
IApplicationActivationManager implements the IForegroundTransfer interface,
which lets us specify if the launched app is allowed to create a window
that steals focus (assuming our process has such ability). By default that
setting is disabled, so launched apps appear in the background and do not
get focus.
See XDG activation (Wayland) and the Startup notification specification (X11)
for equivalent functionality on Unix.
Support for focus-stealing can be set in GAppLaunchContext subclasses like
GdkAppLaunchContext, see gdk_app_launch_context_set_timestamp [1].
[1] https://docs.gtk.org/gdk4/method.AppLaunchContext.set_timestamp.html
GdkAppLaunchContext for Wayland / X11 fetch an opaque token
from the compositor.
On Windows, the system doesn't give you any token. Instead,
the token is implicit, and you can pass that to other
processes via dedicated APIs like AllowSetForegroundWindow.
Due to that, we use an internal format for startup-notify-id
that lets us check what to pass to activated apps.
Currently, the `GDesktopAppInfo` constructors return an error if
validity checks for the `Exec=` line, or other lines, fail. However,
they were ignoring the validity checks done at the `GKeyFile` level, for
invalid UTF-8 or string escaping.
It seems consistent to error out for those too, rather than pretending
that the key file line wasn’t set at all (i.e. treating it like `NULL`).
Spotted by Daniel Kondor.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3771
In the case where mimeapps.list is a symlink, gio-issued updates would
overwrite the file, destroying the symlink in the process.
Instead, this approach recursively follows mimeapps.list symlinks
and overwites the contents of the final file instead.
Closes#3579
It’s possible for the dispatch of the timeout source to race with the
finalisation of the `GMemoryMonitorPoll`, given that the timeout is run
in the GLib worker thread.
Protect against that by holding a thread-safe weak ref on the
`GMemoryMonitor` in the callback data.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3758
Try to avoid casting variables to potentially smaller types to fit
defined probes. This can truncate values and lead to wrong results.
Also make sure that signedness matches.
Since GType can be even 128 bit on CHERI architecture, cast all these
various types used based on platform to uintmax_t which SystemTap
properly processes.
