"Set Up Flathub?" dialog does not appear if background service is active

[AsciiWolf]

Describe the bug

Originally reported in the following places as the Bazaar 0.7.8 issue:

#1108 (comment)

https://bugs.launchpad.net/ubuntu/+source/bazaar/+bug/2148367

However, the same issue happens with latest Bazaar from Git.

When Bazaar is started for the first time on a system without the Flathub remote added, "Set Up Flathub?" dialog should appear. However, this dialog will never appear if the Bazaar background service gets activated before (for example by opening the GNOME "Shell Overview" and searching for some app by typing its name there).

Workaround is to open Bazaar right after the login by clicking its desktop entry in the GNOME "Shell Overview" instead of typing its name, but it is far from being an ideal solution.

OS

Ubuntu 26.04 (GNOME 50)

Version

Latest Bazaar from Git main (pre 0.7.15 release).

Configured Flatpak Remotes

none

Hardware

No response

Extra information or context

Note that once this is fixed, I plan to backport the fix to Ubuntu 26.04.

[AsciiWolf]

You can also reproduce this issue with current Flathub version of Bazaar (0.7.14) by running:

(Can't test it properly since the Flathub version does not seem to support the background service.)

# Warning: This will remove the system flathub remote! You can re-add it later.
$ flatpak remote-delete flathub --force
$ flatpak kill io.github.kolunmi.Bazaar
$ flatpak run --command=sh io.github.kolunmi.Bazaar
[📦 io.github.kolunmi.Bazaar ~]$ bazaar --no-window

And on second terminal:

$ flatpak run io.github.kolunmi.Bazaar

This (if I am correct) will mimic the behavior of dbus-activated background service from non-Flatpak version and results in the same issue with the "Set Up Flathub?" dialog not being displayed.

[AsciiWolf]

I am not a big fan of using LLMs for actual programming, but they have proven to be quite useful for debugging. So I have decided to ask Claude Code about this issue and here is its complete answer:

claude_answer.pdf

(See the "bz-application.c uploaded" part.)

I didn't check if it is correct though. :-)

[AsciiWolf]

tl;dr: Here's what Claude Code suggested as the possible fix:

(Note: I did not check if it is correct or complete nonsense. :))

The Bug — Exact Root Cause
The "Set Up Flathub?" dialog lives inside init_fiber (lines 1012–1075), and is guarded by this
check:

window = gtk_application_get_active_window (GTK_APPLICATION (self));
if (window != NULL)
{
// ... create and present the AdwAlertDialog
}
// response stays NULL → installation silently skipped

Normal launch: bz_application_command_line starts the daemon (init_fiber) and calls
new_window in the same handler (line 543). By the time init_fiber reaches the Flathub check,
the window already exists → get_active_window() returns it → dialog shows. ✅

--no-window pre-start: new_window is never called. init_fiber completes the Flathub check
with get_active_window() == NULL → the entire dialog block is silently skipped →
has_flathub stays false and gets committed to state via
bz_state_info_set_has_flathub(self->state, FALSE). When the user later opens
Bazaar normally, command_line_handler sees self->running == TRUE and skips the
daemon init entirely. The fiber has already run to completion. The dialog will never be shown. ❌

This isn't a race condition per se — it's a missed rendezvous: the only moment the question is ever
asked is during init_fiber, and if no window exists at that exact moment, the question is silently
dropped forever.

The Fix
The cleanest minimal-impact fix is two changes:

1. Add a flag to the struct

// in struct _BzApplication:
gboolean pending_flathub_dialog;

2. Set the flag in init_fiber when the window is absent

// around line 1017 — change this:
window = gtk_application_get_active_window (GTK_APPLICATION (self));
if (window != NULL)
{
// ... existing dialog code ...
}
// to this:
window = gtk_application_get_active_window (GTK_APPLICATION (self));
if (window != NULL)
{
// ... existing dialog code (unchanged) ...
}
else
{
/* Service was started headlessly (--no-window). Defer the dialog
* until the first window is actually created. */
self->pending_flathub_dialog = TRUE;
}

3. Drain the flag in new_window
   new_window needs to show the dialog if the deferred flag is set. Because init_fiber is a libdex
   fiber that dex_awaits the dialog response, extract the dialog interaction into a small helper fiber and
   spawn it from new_window:

BZ_DEFINE_DATA (
show_flathub_dialog,
ShowFlathubDialog,
{ GWeakRef *self; },
BZ_RELEASE_DATA (self, bz_weak_release))
static DexFuture *
show_flathub_dialog_fiber (ShowFlathubDialogData *data)
{
g_autoptr (BzApplication) self = NULL;
GtkWindow *window = NULL;
AdwDialog *alert = NULL;
g_autofree char *response = NULL;
g_autoptr (GError) local_error = NULL;
bz_weak_get_or_return_reject (self, data->self);
window = gtk_application_get_active_window (GTK_APPLICATION (self));
if (window == NULL)
return dex_future_new_true ();
alert = adw_alert_dialog_new (NULL, NULL);
/* ... same heading/body/responses setup as the existing block ... */
adw_dialog_present (alert, GTK_WIDGET (window));
response = dex_await_string (
bz_make_alert_dialog_future (ADW_ALERT_DIALOG (alert)), NULL);
if (g_strcmp0 (response, "add") == 0)
{
gboolean result = dex_await_boolean (
bz_flatpak_instance_ensure_has_flathub (self->flatpak, NULL),
&local_error);
if (result)
bz_state_info_set_has_flathub (self->state, TRUE);
else
g_warning ("Failed to install flathub: %s", local_error->message);
}
return dex_future_new_true ();
}
Then in new_window, after gtk_window_present:
gtk_window_present (GTK_WINDOW (window));
if (self->pending_flathub_dialog)
{
g_autoptr (ShowFlathubDialogData) data = show_flathub_dialog_data_new ();
self->pending_flathub_dialog = FALSE;
data->self = bz_track_weak (self);
dex_future_disown (dex_scheduler_spawn (
dex_scheduler_get_default (),
bz_get_dex_stack_size (),
(DexFiberFunc) show_flathub_dialog_fiber,
show_flathub_dialog_data_ref (data),
show_flathub_dialog_data_unref));
}
return GTK_WINDOW (window);

Why not just g_idle_add?
Because the dialog response is awaited with dex_await_string — that's a blocking-style fiber
await. It must live in a dex fiber, not a plain GSourceFunc. Spawning a fiber (as above) is the correct
idiom already used everywhere else in this file for exactly this pattern.

Edge case: init_fiber still in-flight when window opens
If the service was started without --no-window but the machine is very slow, new_window could
be called before init_fiber reaches the Flathub check. In that case
pending_flathub_dialog is still false when new_window runs, and the existing path in
init_fiber handles it (window will already exist). The flag only fires in the scenario where
init_fiber has already passed the check with no window present — so there's no double-dialog
risk.

[kolunmi]

I'll make sure to address this before the next update!