GNOME Bugzilla – Bug 643224
GIO may block on the network when launching/querying default program
Last modified: 2018-05-24 12:59:01 UTC
Created attachment 181862 [details] 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.
Created attachment 181863 [details] [review] [PATCH 1/2] Add g_file_query_default_handler_async and the corresponding finish
Created attachment 181864 [details] [review] [PATCH 2/2] Add asynchronous version of g_app_info_launch_default_for_uri
I don't think you need async versions of gtk_show_uri. Just make it non-blocking. Launching an application is generally a somewhat async operation anyway.
Yeah, that was my first thought as well (and requiring the async/callback/finish incantation is incredibly obnoxious). But gtk_show_uri does currently have a return value, and gnome-terminal at least will display an error dialog if it returns false; I imagine other tools do the same? Of course, if the launched program fails to open the file for some reason, we won't get an answer, and it'll be the launchee's job to report the error (and gtk_show_uri's return value will not reflect this). It could fail earlier. For instance, if no program could be found, gtk_show_uri currently returns FALSE and it is (I think correctly) the caller's job to report the error to the user. (I imagine if the program couldn't be forked, gtk_show_uri also reports the error.) Since figuring out if there is a program to open should be done asynchronously, I don't know if gtk_show_uri can avoid being async too. Perhaps instead of async it could just take an completion callback? That might be cleaner than a full-blown gtk_show_uri_async/GAsyncResult/gtk_show_uri_finish. combination.
I guess we could cheat and make it always return TRUE And maybe add a gtk_show_uri_full version that takes a completion callback, if anybody asks for it.
Maybe. Judging from Google codesearch, people seem to mostly check the error code (among projects indexed) as a fallback to pick a different browser. Other than that, the most common (and sensible) response is to display the error in a popup or part of the UI. Especially since GTK3 was only just released, perhaps it's not too terrible to have gtk_show_uri asynchronously pop open a dialog when necessary. We could insist that any GTK3 users wanting a custom error thing use gtk_show_uri_full. I guess we'd also lose the error popup's parent window in the cheating error dialogs.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/394.