GNOME Bugzilla – Bug 666386
Empathy doesn't open Redirect URI with particular characters
Last modified: 2012-05-18 16:18:02 UTC
Originally reported at: https://bugs.launchpad.net/bugs/794932 empathy does not open the url in the chat.it should open in the default browser Binary package hint: empathy Empathy 2.32.1 - Ubuntu 10.10 I have received a link (http://sourceforge.net/projects/phpmyadmin/files%2FphpMyAdmin%2F3.4.2%2FphpMyAdmin-3.4.2-all-languages.tar.gz/download#!md5!589b26fa2f1bdb21b4114f3be6aa3b65 ) in a chat, but when I click it, empathy doesn't open it but instead appear a popup that report: Unable to open URI - Operation not supported The link point to the latest version of phpmyadmin, and with a cut and paste in a browser, open the download dialog. I think the problem is related to this particular URI because other URI work right, opening in the default browser (Firefox).
Which exact Empathy version is this about, as you wrote "2.32.1" while you set the version field to 3.3.x?
the version i am using is 3.3.3
Humm that's weird, the generated HTML in the webkit theme looks fine: <a href="http://sourceforge.net/projects/phpmyadmin/files%2FphpMyAdmin%2F3.4.2%2FphpMyAdmin-3.4.2-all-languages.tar.gz/download#!md5!589b26fa2f1bdb21b4114f3be6aa3b65">http://sourceforge.net/projects/phpmyadmin/files%2FphpMyAdmin%2F3.4.2%2FphpMyAdmin-3.4.2-all-languages.tar.gz/download#!md5!589b26fa2f1bdb21b4114f3be6aa3b65</a> Kov: any idea?
Apparently gtk_show_uri doesn't like that URI because it causes redirects before showing the actual content. See empathy-ui-utils.c:1733. This is a bug in gtk+ IMO. Here's a quick python snippet to repro: >>> from gi.repository import Gtk >>> Gtk.show_uri (None, 'http://sourceforge.net/projects/phpmyadmin/files%2FphpMyAdmin%2F3.4.2%2FphpMyAdmin-3.4.2-all-languages.tar.gz/download#!md5!589b26fa2f1bdb21b4114f3be6aa3b65', Gtk.get_current_event_time()) Traceback (most recent call last):
+ Trace 229462
return info.invoke(*args, **kwargs)
Thanks, re-assigning to Gtk+ then.
gtk_uri_show fails, because g_app_info_launch_default_for_uri() fails. g_app_info_launch_default_for_uri() fails because g_file_query_default_handler() fails. g_file_query_default_handler() fails because g_file_get_uri_scheme() returns NULL.
(In reply to comment #6) > gtk_uri_show fails, because g_app_info_launch_default_for_uri() fails. > g_app_info_launch_default_for_uri() fails because > g_file_query_default_handler() fails. > g_file_query_default_handler() fails because g_file_get_uri_scheme() returns > NULL. and g_file_get_uri_scheme() returns NULL because g_vfs_decode_uri() rejects URIs that have "%2F" in the path, and so you end up getting back a GDummyFile, and gdummyfile.c:_g_decode_uri() likewise rejects the URI, so the returned GFile has a NULL URI. This is not fixable within GFile without breaking its API; GFile doesn't have any way of escaping characters in pathnames, so it can't represent a path that contains a "/" that is not a directory separator. But we can just avoid using GFile here...
Created attachment 214307 [details] [review] g_app_info_launch_default_for_uri: don't use GFile if we don't have to GFile doesn't handle some "real" URIs, so check if there's a default handler for the URI scheme first, and only use g_file_new_for_uri() and g_file_query_default_handler() if not. Eg, this fixes the case of opening http URIs with "%2F" in the path. ==== (see also bug 676313)
I would keep the existing comment and add to it instead, but looks good to me.
Review of attachment 214307 [details] [review]: Looks good to me too. Bug 665379 is essentially the same issue, I'll check the gvfs part, smelling something rotten...
added back a comment about not using the GFile's URI Attachment 214307 [details] pushed as 555cd19 - g_app_info_launch_default_for_uri: don't use GFile if we don't have to