Most likely unrelated to gvfs itself. What are you actually calling?

Calling g_app_info_get_default_for_uri_scheme() is fast. g_app_info_launch_default_for_uri() is also very fast. I tested both in a simple test program.

gtk_show_uri() is slow, but g_app_info_launch_default_for_uri() is fast.

---8<---
#include <gtk/gtk.h>

int main (int argc, char **argv)
{
	guint i;

	gtk_init (&argc, &argv);

//	gtk_show_uri (NULL, "https://bugzilla.gnome.org/show_bug.cgi?id=635588", 0L, NULL);
	g_app_info_launch_default_for_uri ("https://bugzilla.gnome.org/show_bug.cgi?id=635588", NULL, NULL);

	return 0;
}
---8<---

This code shows the problem. With a context, it takes a couple of seconds
before launching the app, without it, it works as expected.

--8<--
#include <gtk/gtk.h>

int main (int argc, char **argv)
{
        GdkAppLaunchContext *context;

        gtk_init (&argc, &argv);

        context = gdk_app_launch_context_new (); 
        gdk_app_launch_context_set_screen (context, gdk_screen_get_default ());
        gdk_app_launch_context_set_timestamp (context, GDK_CURRENT_TIME);

        g_app_info_launch_default_for_uri
("https://bugzilla.gnome.org/show_bug.cgi?id=635588", (GAppLaunchContext *)
context, NULL);
//      g_app_info_launch_default_for_uri
("https://bugzilla.gnome.org/show_bug.cgi?id=635588", NULL, NULL);

        return 0;
}
--8<--

Committed a workaround

(In reply to comment #4)
> Committed a workaround

Where did you commit this, please? I'm using gtk-2-24 branch and I still see it there, more that that the 
  $ git log | grep 635588
shows empty result. I'm at commit 6e2573f right now.

Milan, the patch was applied in master:

http://git.gnome.org/browse/gtk+/commit/?id=b0bf2b5202782526edcba678c6239baecf897b16

Ah, thanks, can it be committed to gtk-2-24 too, please?

Sure, it can

Pushed in gtk-2-24 branch: http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=b2274ba08a832e9e8299f4d2642f1f38a4a7c4c3

*** Bug 636866 has been marked as a duplicate of this bug. ***

I'm at gtk+ commit 5c3b49a and I still see a delay. My network is not so quick, so it can be the reason. I also see a new application "Opening show_bug.cgi" in the task bar, between my other applications, though clicking this button doesn't do anything (it doesn't show the window). I believe that this thing is causing all the trouble.

I also realized I cannot pass partial URL to the browser, (I expect gtk_open_uri function is meant to do it for me, especially with uris beginning with http/https). As an example, opening URL:
   https://admin.fedoraproject.org/pkgdb/acls/name/
results in 500 error in the browser, which I believe is fine, because I will type a package name at the end and be happy, but right now, with the above mentioned gtk+ commit, I get an error instead "HTTP Error: Internal error", so the ling doesn't get it to the browser at all.

I do not think this is the right thing to be done and I believe this is caused be the "Opening..." application which is causing the page being opened twice, once in that application to verify the URL (an unnecessary step), and the second time when the browser itself opens the page again. Imagine a large page, or slow network/server, then there is a) delay, b) unnecessary load on the server doing each request twice. When the only thing to be done is to pass the URL to the application registered as a handler for the http/https uris.

If you are wondering, my glib commit is a57c4c9 and my gvfs commit is 9fb3e91.

I'm setting this to blocker.
a) it is still slow, nothing from the above helped at all when the server is slow (the application which is invoking the link is stuck with no response for couple seconds)
b) more importantly, I have a valid URL which I'm trying to open, which requires authentication, which, you may not believe me, the browser knows about and has credentials already, but I get only an error response from the function call:
  HTTP Client Error: Authorization Required
and I'm forced to copy&paste the URL from my mail window to the browser, instead of just clicking on it.
c) when I have an http/https url which results in text/plain content then it's opened in gedit instead of the web browser. It's really not that what I want from it. Try clicking this URL [1] from terminal, for example.

You really shouldn't check the content before passing URL to the browser, which knows much better what to do with the URL than "you". Apart of the above, please try with slow connection and slow server too. You may finally realize what I'm talking about.

I'm at glib commit 401a423 and gvfs commit 10f4959.

[1] http://bugzilla-attachments.gnome.org/attachment.cgi?id=172711

I just got an issue in valgrind and they write URL as this:
   www.valgrind.org
in the middle of the text on a terminal. I can click above it and choose "Open link", but it is not opened anyway, the error message is shown instead:

   Could not open the address “http:www.valgrind.org”
   Automount failed: Invalid mount spec

When talking about terminals, if I have opened multiple of them, and try to open a url from a slow server in one of them, then all other terminals are frozen as well, they even do not paint. I was told that it's because multiple terminal windows are handled by one terminal process, which can make sense.

This probably shouldn't be a blocker since it's been in that state for nearly four months without any movement… Milan, are you still seeing these problems or have other issues been at play here?

OK, I have installed Fedora 15 with glib2-2.28.6-2.fc15.x86_64 and:
From comment #11, partial uri, is not there, I can use that sample URL.

From comment #12:
ad b), authenticated urls, are passed into the browser too.
ad c), text/plain parts, maybe I have something disabled here, but it seems it doesn't suffer of that too

From comment #13, the www.valgrind.org is openable.

So yes, this is fixed with that version. Thanks for a reminder and "silent" fixes.