0

I'm packaging a Flatpak application that checks the network availability on startup. Since switching to Flatpak packaging I've noticed that the GLib.NetworkMonitor is initially reporting no network availability, but very shortly thereafter the network-changed signal is emitted to indicate that there is a network connection.

This appears to be Flatpak related - maybe due to the sandbox not having a connection initially?

I don't see this behavior documented anywhere, so I don't want to assume that there will always be a signal emitted initially.

public class MyApplication : Gtk.Application {

    private bool is_network_available;

    construct {
        // After the application is fully started, UI initialized, etc. this gets
        // triggered and reports change to `true`
        network_monitor.network_changed.connect (() => {
            debug ("Network availability changed: %s", network_monitor.get_network_available ().to_string ());
        });
    }
    
    protected override void activate () {
        // Check the initial state of the network connection
        is_network_available = network_monitor.get_network_available ();
        debug (is_network_available); // Reports false
    }
    
}

Is this expected for Flatpak packaged applications? Is there a more reliable method to perform this check on startup?

avojak
  • 2,342
  • 2
  • 26
  • 32

1 Answers1

2

It’s a bug in GLib: https://gitlab.gnome.org/GNOME/glib/-/issues/1718

For the moment you will have to work around it some way. Assuming that a signal will always be emitted on startup is not guaranteed behaviour, so if you use that as a workaround you should make it conditional on the GLib version, and disable your workaround code if built against a version of GLib which is fixed. (No versions of GLib are fixed yet, though.)

Philip Withnall
  • 5,293
  • 14
  • 28
  • Ah thank you for linking to that issue! I looked for quite a while but was too narrowed-in on Flatpak specifically. Rather unfortunate that they don’t seem to really acknowledge this as an issue… Anyway, thanks again for the info! – avojak Nov 22 '21 at 16:46
  • 1
    It’s acknowledged as an issue (the bug report is still open), but it’s not clear what the best way of fixing it is, without breaking other things in the process. That’s exacerbated by the fact there are very few development resources upstream, which is why no fix has been worked on yet. It’ll get fixed eventually; faster if someone steps up to come up with a solution :) – Philip Withnall Nov 23 '21 at 11:56
  • That's fair and totally understandable! It was the "add a 0.5 sec sleep" and "The solution is fixing the app" comments that rubbed me the wrong way. – avojak Nov 23 '21 at 14:52
  • Understandable! – Philip Withnall Nov 24 '21 at 00:34