GNOME Bugzilla – Bug 780441
Make the portal implementation of g_app_info_launch() synchronous
Last modified: 2017-03-23 14:22:01 UTC
As agreed during the GTK+ hackfest [1], "we decided to make the g_app_info_launch portal implementation a little more synch to help xdg-open", in order to "protect" the logic from not ever having the remote method running in case the xdg-desktop-portal process is not yet running and the caller quits quickly after the call. This should not be a problem as the method returns immediately (regardless of the user making a selection), but making it synchronous would prevent situations where the OpenURI method would never be called because of D-Bus dropping the message after the caller dies, without explicitly waiting for a reply. [1] https://wiki.gnome.org/Hackfests/GTK2017/Day3
Created attachment 348560 [details] [review] appinfo: Don't leak the session bus in launch_default_with_portal_async The session bus object needs to be unreferenced before early returning.
Created attachment 348561 [details] [review] appinfo: Launch the OpenURI portal using a synchronous D-Bus call Calling the D-Bus method for the OpenURI portal "protects" the logic from not ever having the remote method running in case the xdg-desktop-portal process is not yet running and the caller quits quickly after the call. This should not be a problem as the method returns immediately (regardless of the user making a selection), but making it synchronous would prevent situations where the OpenURI method would never be called because of D-Bus dropping the message after the caller dies, without explicitly waiting for a reply.
Review of attachment 348560 [details] [review]: oops, ok
Review of attachment 348561 [details] [review]: ok
Thanks, all landed in master: https://git.gnome.org/browse/glib/commit/?id=26e0b3dde4bfb32eb10658140b9f63e04f76b60e https://git.gnome.org/browse/glib/commit/?id=b374cc2e236396fb556891427d58aed81ceded63
(In reply to Mario Sánchez Prada from comment #0) > making it synchronous would prevent > situations where the OpenURI method would never be called because of D-Bus > dropping the message after the caller dies, without explicitly waiting for a > reply I think the issue here might be the caller dying before it has even finished the authentication handshake. I believe dbus-daemon is meant to finish processing queued *messages* before removing the caller's connection (although of course bugs are possible), but it can't do that if the caller hasn't even finished authenticating yet, and in GDBus-world, the handshake might well be async too. (If I am right about that, then libdbus has an API bug that makes it avoid that issue: opening the connection, which includes the auth handshake, is always similar to g_bus_get_sync(), and never g_bus_get().)