GNOME Bugzilla – Bug 617874
g_app_info_launch_default_for_uri is not working on windows
Last modified: 2018-05-24 12:16:54 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.
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
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.
Created attachment 160415 [details] [review] Working uri-launcing done by windows api
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.
*** Bug 602968 has been marked as a duplicate of this bug. ***
*** Bug 615983 has been marked as a duplicate of this bug. ***
*** Bug 623898 has been marked as a duplicate of this bug. ***
There is a patch available in https://bugzilla.gnome.org/show_bug.cgi?id=623898#c0 http://git.gnome.org/browse/gnumeric/plain/tools/win32/patches/glib-appinfo.patch
Regarding that patch: note my speculation that it needs a small fix so it won't break file:// URIs.
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)
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.
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
(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.
hmm... yes, my patch does check for :// Porbbaly easily fixable in the gwinhttpvfs.c part of the patch
*** Bug 590191 has been marked as a duplicate of this bug. ***
any updates on this one?
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!
*** Bug 783824 has been marked as a duplicate of this bug. ***
-- 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.