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 617874 - g_app_info_launch_default_for_uri is not working on windows
g_app_info_launch_default_for_uri is not working on windows
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
2.24.x
Other Windows
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 590191 602968 615983 623898 783824 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-05-06 09:36 UTC by Fridrich Strba
Modified: 2018-05-24 12:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A minimum test case (326 bytes, text/x-csrc)
2010-05-06 09:36 UTC, Fridrich Strba
  Details
Working uri-launcing done by windows api (172 bytes, patch)
2010-05-06 09:43 UTC, Fridrich Strba
none Details | Review

Description Fridrich Strba 2010-05-06 09:36:56 UTC
Created attachment 160413 [details]
A minimum test case

The attached test program is doing the right thing on linux, but errors out on windows.
Comment 1 Fridrich Strba 2010-05-06 09:40:50 UTC
Just to be precise, launching with http://www.gtk.org is opening the link in browser on linux, saying that no handler is associated with that schema on windows.
launching mailto:fridrich.strba@bluewin.ch launches the default mail composer on Linux, and says that Launching failed: Error stating file 'Z:\hostfs\home\fstrba\mailto:fridrich.strba@bluewin.ch': No such file or directory
Comment 2 Fridrich Strba 2010-05-06 09:42:59 UTC
The following attached program using purely windows api to launch default uri handlers will open the link and the mailto: uri correctly. So the handler are actually registered.
Comment 3 Fridrich Strba 2010-05-06 09:43:52 UTC
Created attachment 160415 [details] [review]
Working uri-launcing done by windows api
Comment 4 Tor Lillqvist 2010-05-06 11:28:18 UTC
It seems that one problem here is that g_app_info_get_default_for_type() in gwin32appinfo.c calls AssocQueryString() with a content-type (i.e. a string like "text/html") even if that is not the kind of strings that AssocQueryString() expects. The docs say: 

 "The following four types of strings can be used
    File name extension -- A file name extension, such as .txt.
    CLSID -- A class identifier (CLSID) GUID in the standard "{GUID}" format.
    ProgID -- An application's ProgID, such as Word.Document.8.
    Executable name -- The name of an application's .exe file.
 "

No mention of content-types. In fact, content-types play a much smaller role in the Win32 API than on modern Unix systems. Some relatively radical refactoring/rewriting of the code as used on Windows is needed.

I get the feeling that at least in this case (where the app calls g_app_info_launch_default_for_uri()), GIO tries to do way too much itself, when it on Windows would work best and be simplest to just call a suitable Win32 API (ShellExecute()) right in g_app_info_launch_default_for_uri()... Dunno then for other use cases of GAppInfo &co.
Comment 5 Alexander Kojevnikov 2010-07-10 10:44:10 UTC
*** Bug 602968 has been marked as a duplicate of this bug. ***
Comment 6 Alexander Kojevnikov 2010-07-10 10:44:30 UTC
*** Bug 615983 has been marked as a duplicate of this bug. ***
Comment 7 Alexander Kojevnikov 2010-07-10 10:46:24 UTC
*** Bug 623898 has been marked as a duplicate of this bug. ***
Comment 9 Morten Welinder 2010-07-10 16:51:17 UTC
Regarding that patch: note my speculation that it needs a small fix so
it won't break file:// URIs.
Comment 10 Owen Taylor 2010-09-06 21:49:16 UTC
While a complicated fix might be the right thing to do here, if reviewing the big patch is too hard, couldn't you do a simple patch to:

static gboolean
g_win32_app_info_launch_uris (GAppInfo           *appinfo,
                              GList              *uris,
                              GAppLaunchContext  *launch_context,
                              GError            **error)
{
  GList *files = NULL;
  GList *l;
  result = FALSE;

  for (l = uris; l; l = l->next)
    {
       char *path = g_file_get_path (l->data);
       if (path == NULL) 
         {
           g_set_error_literal (error, G_IO_ERROR, 
                                G_IO_ERROR_NOT_SUPPORTED, 
                               _("Non-file URIs not supported"));
           goto out;
        }
       files = g_list_prepend(files, path);
     }

  files = g_list_reverse(files);
  result = g_win32_app_info_launch_files(app_info, files, launch_context, error);

out:
  g_list_foreach (files, (GFunc)g_free, NULL);
  g_list_free (files);

  return result;
}

(Or without the reflexive prepend/reverse optimization)
Comment 11 Owen Taylor 2010-09-06 22:36:19 UTC
That pseudo-patch was obviously junk. Something more like:

static gboolean
g_win32_app_info_launch_uris (GAppInfo           *appinfo,
                              GList              *uris,
                              GAppLaunchContext  *launch_context,
                              GError            **error)
{
  GList *files = NULL;
  GList *l;
  result = FALSE;

  for (l = uris; l; l = l->next)
    {
       GFile *file = g_file_new_for_uri (l->data);
       files = g_list_prepend(files, file);
     }

  files = g_list_reverse(files);
  result = g_win32_app_info_launch_files(app_info, files, launch_context,
error);

  g_list_foreach (files, (GFunc)g_object_unref, NULL);
  g_list_free (files);

  return result;
}

Then add to:

g_win32_app_info_launch()

  char *path = g_file_get_path (l->data);
-     wchar_t *wfilename = g_utf8_to_utf16 (path, -1, NULL, NULL, NULL);
+     wchar_t *wfilename;
+
+  if (path == NULL)
+    {
+        g_free (path);
+        g_set_error_literal (error, G_IO_ERROR, 
+                                G_IO_ERROR_NOT_SUPPORTED, 
+                               _("Only local files are supported"));
+        return;
+    }
+    wfilename = g_utf8_to_utf16 (path, -1, NULL, NULL, NULL);      

      g_free (path);

The point anyways is that a "URI" is just another representation of a GFile, so if you can handle GFiles, you can handle URIs.
Comment 12 Morten Welinder 2010-09-06 23:48:44 UTC
Owen: I don't think you appreciate how broken URI parsing is on glib/win32.
It will see foo://bar as a directory "foo:" with a file "bar" in it.

My current patch lives at:
http://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/glib-appinfo.patch
Comment 13 Fridrich Strba 2010-09-07 07:58:38 UTC
(In reply to comment #12)
> My current patch lives at:
> http://git.gnome.org/browse/gnumeric/tree/tools/win32/patches/glib-appinfo.patch

Morten, your patch works very well with http:// urls now. Nevertheless, if you click on a link containing a mailto link, gio thinks you are wanting to access a file designed by a relative path maito:someone@email.com and will report that the c:\path\of\the\exe\mailto:someone@email.com is not found.
Comment 14 Morten Welinder 2010-09-07 14:02:05 UTC
hmm...  yes, my patch does check for ://

Porbbaly easily fixable in the gwinhttpvfs.c part of the patch
Comment 15 Matthew Barnes 2010-09-11 05:00:02 UTC
*** Bug 590191 has been marked as a duplicate of this bug. ***
Comment 16 Tao Wang 2011-12-04 15:58:21 UTC
any updates on this one?
Comment 17 Fan, Chun-wei 2014-05-16 02:51:12 UTC
Hi,

I think this problem has something to do with bug 729988, as we would always try to load a built in GIO "module" for vfs handling, as GLIB_PRIVATE_CALL (g_check_setuid) is always going to return FALSE on Windows (and most probably non-UNIX, and we don't have a gvfs module for Windows, besides the built-in winhttp "module"), which I don't think gets loaded in this case.

It would be great if someone can look at my patch there (it may not be totally right, IMO, but it is what I can come up with at this moment), so that we will always try to use the vfs implementation returned by g_vfs_get_local() on non-UNIX until if and when we have a gvfs module for Windows.  Any comments and suggestions on these is really appreciated.

With blessings, thank you!
Comment 18 Philip Withnall 2017-06-16 09:33:59 UTC
*** Bug 783824 has been marked as a duplicate of this bug. ***
Comment 19 GNOME Infrastructure Team 2018-05-24 12:16:54 UTC
-- 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/292.