After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748063 - open folder from chromium needs 2 clicks
open folder from chromium needs 2 clicks
Status: RESOLVED DUPLICATE of bug 746534
Product: glib
Classification: Platform
Component: gio
2.45.x
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-04-17 15:56 UTC by haheute
Modified: 2015-05-24 20:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
desktopappinfo: synchronously create DBus proxy to activate application (2.77 KB, patch)
2015-05-24 17:51 UTC, Cosimo Cecchi
none Details | Review
desktopappinfo: synchronously flush the session bus after spawn (1.41 KB, patch)
2015-05-24 17:52 UTC, Cosimo Cecchi
none Details | Review

Description haheute 2015-04-17 15:56:25 UTC
When a download is finished in chromium browser, a bottom bar shows the downloaded files and offers to open the containing directory in nautilus.

With nautilus 3.16.1 on archlinux, after the first click, nothing seems to happen but after the second click, nautilus opens the folder as expected. nothing wrong, just 2 clicks needed instead of one.

Sorry if this is not a gnome issue - I am not sure.
Comment 1 Carlos Soriano 2015-04-22 12:20:03 UTC
Hi, in 3.16.1 we changed something there. The thing is that I cannot reproduce your issue.

Can you install d-feet. Select session bus. Selec freedesktop.FileManager1 -> /org/freedesktop/FileManager1 -> interfaces org.freedesktop.FileManager1.ShowItems
and then write something like
['file:///home'],''
and execute.

Does that works?
Comment 2 haheute 2015-04-22 12:33:37 UTC
Hello. Thanks.

I can select "Session Bus" and "org.freedesktop.FileManager1". But when I click further,  "/org/freedesktop/FileManager1" or "/org/gnome/Nautilus" , the menu closes and brings me back to "Session Bus" overview after 2 or 3 seconds..
Comment 3 Cosimo Cecchi 2015-05-23 23:44:50 UTC
This can be reproduced easily with e.g. "gvfs-open /home/cosimoc"
Comment 4 Cosimo Cecchi 2015-05-24 17:23:10 UTC
-> gio

The bug is not in Nautilus, but in gvfs-open/GIO after the introduction of dbus activatable applications. It can be reproduced when gvfs-open tries to open any application with DBusActivatable=true in the desktop file.

gvfs-open calls g_app_info_launch_default_for_uri() which will asynchronously call the "Open" dbus method; but gvfs-open does not have a mainloop, so it immediately quits before the message has ever the chance to reach the session bus.
What is a little odd is that the application still gets autostarted - it's just the "Open" message that is not transmitted. Calling gvfs-open a second time when the application was previously activated already will correctly deliver the message. This is perhaps because when there is no owner for the application bus name, GDBus will first activate it and only after call the Open method, with the request in queue getting dropped when the program quits.

I've tried several approaches:
- adding a mainloop to gvfs-open. This works fine, but we have no chance to know when the application has been started to quit the mainloop.
- making the call to open in gdesktopappinfo.c [1] synchronous. This just works with no other side effects for gvfs-open, but comments in the GIO code hint that the call being asynchronous is very much intentional, since the API is in general non-blocking.
- flushing synchronously after the call. This does not work.

So I'm looking for another solution here and I'm open to suggestions. The next thing I was going to try is to create a dbus proxy for the application synchronously, and then call Open asynchronously. That is in my mind roughly equivalent to the synchronous fork/exec that would happen in the spawn case.
Another option would be to add an asynchronous API that allows a main loop in gvfs-open, but I was trying to avoid that...

[1] https://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c#n2876
Comment 5 Cosimo Cecchi 2015-05-24 17:51:55 UTC
Created attachment 303885 [details] [review]
desktopappinfo: synchronously create DBus proxy to activate application

In order to guarantee that all messages required for activation are
delivered to the session bus even without a mainloop, we synchronously
create a GDBusProxy for the application we're about to call into, to
make sure it's activated before we send our next request.
Comment 6 Cosimo Cecchi 2015-05-24 17:52:00 UTC
Created attachment 303886 [details] [review]
desktopappinfo: synchronously flush the session bus after spawn

This will ensure all pending activation messages reach the session bus
even when a mainloop is not running.
Comment 7 Cosimo Cecchi 2015-05-24 17:55:07 UTC
These patches make gvfs-open work again, but they're not exactly great.

I am now even more convinced of the theory that GDBus queues messages when there's no name owner for the proxy until the mainloop is re-entered with a name owner, as despite the sync flush and sync proxy creation, I can still reproduce the issue if I e.g. pass G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START_AT_CONSTRUCTION to the proxy constructor.

Ryan, what do you think?
Comment 8 Emmanuele Bassi (:ebassi) 2015-05-24 20:58:47 UTC
This issue is already being tracked, with an analysis and patches, in bug 746534.

*** This bug has been marked as a duplicate of bug 746534 ***