[Bug]: Should check for full network connectivity using NetworkManager before attempting anything

nekohayo commented 1 year ago

Describe the bug

If you launch Tuba while your computer is offline (i.e. not connected to wifi or anything), it will get stuck with the Home timeline loading with the spinner churning infinitely, even after the wifi has connected, even if you switch between tabs or sidebar categories in Tuba, when you go back to the "Home" area (or whatever you were trying to load while offline) it remains unable to retry loading it, it just keeps showing the blank slate and spinner.

So basically this is two things:

Tuba should use NetworkManager to know if the user is fully online (not oflline, not just in a LAN/intranet, and not behind a captive portal). Here's some docs, but I don't know which part is the best way to go about it: https://networkmanager.dev/docs/api/latest/ - I am presuming you are not using NetworkManager because a quick github search didn't show mentions of "nm" (or something that sounded like Network Manager when searching for "network")
Each component of the app should be network-failure resilient and reset its state after a while, or when switching away and back to it, or when using the future refresh/pull-down-refresh functionality, otherwise they might never really recover from that initial offline stage (in case of a bug) or from server-side failure.

Steps To Reproduce

Launch Tuba while your computer is not connected to the Interwebs

Logs and/or Screenshots

No response

Instance Backend

Mastodon

Operating System

Fedora 38

Package

Flatpak

Troubleshooting information

os: GNOME 44 (Flatpak runtime) prefix: /app flatpak: true version: 0.2.0 (production) gtk: 4.10.1 (4.10.1) libadwaita: 1.3.1 (1.3.1) libsoup: 3.4.0 (3.4.0) libgtksourceview: 5.8.0 (5.8.0)

Additional Context

No response

mlundblad commented 1 year ago

Just beware that you might get bug reports from users using custom VPN scripts that don't play nicely with NM (or bypass it).

We had this in Maps with recurring bug reports. Added a --force-online CLI option as a workaround, but eventually bailed, and removed the network check (instead checking status when performing operations such as searching).

CaptainMorgan12 commented 1 year ago

i would not perform network checks within any apps, i think having and loadind old cached messages should be ok, either they are refreshed if network exists, or nothing new or additional is loaded if it doesnt.

nekohayo commented 7 months ago

https://docs.gtk.org/gio/iface.NetworkMonitor.html might be an easier abstraction over NetworkManager, maybe.

GeopJr commented 2 months ago

On #928 (draft), I ended up using NetworkMonitor.

Just beware that you might get bug reports from users using custom VPN scripts that don't play nicely with NM (or bypass it).

We had this in Maps with recurring bug reports. Added a --force-online CLI option as a workaround, but eventually bailed, and removed the network check (instead checking status when performing operations such as searching).

Thanks for the insight! We already have reports about libsoup and proxies so I think this will be unavoidable. Tuba relies 100% on network connections as a social media client so a 'global' check is needed, especially with all the websockets kept alive.

I'll see about a CLI option, though I'm okay with Tuba being the reason any issues with it get attention and fixed.

i would not perform network checks within any apps

The reason it's needed, it's because Tuba can't recover gracefully - if an image tries to load while offline, going online won't cause it to retry getting it - and requires a full app restart ATM (not for timeline images since you can refresh timelines, but for other internal stuff like websockets, announcements, sidebar images, account updates...).

i think having and loadind old cached messages should be ok, either they are refreshed if network exists, or nothing new or additional is loaded if it doesnt.

I'll see about this too. At the current timeline state (ListBox vs ListView), it would require recovering every single attachment. While a refresh is much more straightforward. Additionally, since the websockets will be dead, any new messages between the time the app went offline and came back online, won't exist until a manual refresh.

GeopJr / Tuba