GIO may block on the network when launching/querying default program
Submitted by David Benjamin
Link to original bug (#643224)
Description
Created attachment 181862 Boring g_app_info_launch_default_for_uri test program
To determine the default launcher for a URL, gio will first check if a protocol handler exists. If not, it queries the URL to figure out the type and looks up an appropriate program. The current versions of the relevant functions lack asynchronous variants. Unfortunately, they're called by gtk_show_uri, so this may easily leave a program unresponsive.
An easy way to see this is with a dummy page I put at http://davidben.net/sleep-10s.py It sleeps 10 seconds and then returns with a text/plain payload. In your .local/share/applications/mimeapps.list, add a [Removed Associations] entry and mask out every application on your system which advertises x-scheme-handler/http support.
[Removed Associations] x-scheme-handler/http=google-chrome.desktop;firefox.desktop;blah;blah;blah;
Now open that link, from say, your terminal. Or using the quick test program I've attached. (NB: if gedit is configured to open text/plain on your system, the version on mine makes several calls to the URL, most of which also block and ought to be fixed.)
(Granted, no one would ever want to remove their browser x-scheme-handler/http entries, but this was the easiest case to set up. One could easily imagine an sftp:// link to a very slow server with the same result.)
I've attached[1] patches that add g_file_query_default_handler_async, and g_app_info_launch_default_for_uri_async. If these land, I'll work on the corresponding addition for gtk_show_uri. (I'd argue the blocking versions should be removed altogether because everyone will use them on accident, except that would break backwards-compatibility.)
g_app_info_launch_default_for_uri_async/gtk_show_uri_async are also somewhat obnoxious. It'd be nice for them to be fire-and-forget, but I don't think you can do that short of hard-coding an error dialog in the gtk_show_uri variant. If no matching program can be found, /some/ error should be displayed to the user, and that would be the caller's job.
[1] Or rather, will in a moment. Bugzilla seems to dislike attaching several files at once.
Attachment 181862, "Boring g_app_info_launch_default_for_uri test program":
launch-default-for-uri.c