Firefox 22+ protocol handler doesn't work properly

Bug #1201954 reported by Roman Shipovskij
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
New
Medium
firefox (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

After upgrading to Firefox 22 protocol handler doesn't work properly

for example, when I click on link skype:skype_name?chat I can select Skype from list in Firefox 21- but can't do that in Firefox 22+

Google Chrome, xdg-open works correct

~$ grep x-scheme-handler/skype /usr/share/applications/*
/usr/share/applications/mimeinfo.cache:x-scheme-handler/skype=skype.desktop;
/usr/share/applications/skype.desktop:MimeType=x-scheme-handler/skype;

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: firefox 23.0~b4+build1-0ubuntu0.13.04.1
ProcVersionSignature: Ubuntu 3.8.0-26.38-generic 3.8.13.2
Uname: Linux 3.8.0-26-generic i686
ApportVersion: 2.9.2-0ubuntu8.1
Architecture: i386
BuildID: 20130709135739
Date: Tue Jul 16 23:02:55 2013
InstallationDate: Installed on 2013-02-12 (154 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.2)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=uk_UA.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox
UpgradeStatus: Upgraded to raring on 2013-04-25 (82 days ago)

Revision history for this message
Roman Shipovskij (roman-shipovskij) wrote :
Revision history for this message
Roman Shipovskij (roman-shipovskij) wrote :
Revision history for this message
Roman Shipovskij (roman-shipovskij) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
Roman Shipovskij (roman-shipovskij) wrote :

Same problem on Ubuntu 12.04 LTS

tags: added: precise
Revision history for this message
Shiba (shiba89) wrote :

Same here for apt:// and magnet://

Revision history for this message
Shiba (shiba89) wrote :
Revision history for this message
Mathieu Comandon (strycore) wrote :

*hint* *hint*

commit 744ab38713f2e2a4d765defaed60f2cbefbf3713
Author: Mike Hommey <email address hidden>
Date: Wed Feb 27 14:34:40 2013 +0100

    Bug 444440 - Prioritize mailcap application over others in nsMIMEInfoUnix. r=bzbarsky

 uriloader/exthandler/unix/nsMIMEInfoUnix.cpp | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

Revision history for this message
In , Mathieu Comandon (strycore) wrote :

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36

Steps to reproduce:

Browsing on websites with a custom URL scheme which should open an external application when clicked (such as apt://, steam:// or magnet:// links).

Actual results:

Clicking on such links opens an empty dialog box and the user has to browse the file system to look for the executable, no default choice is proposed (since Firefox 22)

Expected results:

The Application Launch dialog used to show default application that could handle specific types of url schemes (Transmission for magnet: links, software center for apt: link, ...).

I ran a git bisect of revisions between Firefox 21 and Firefox 22 and found out that this was caused by the commit fixing bug #444440 (https://hg.mozilla.org/mozilla-central/rev/f118eb2326f7), reverting the commit did put the expected applications back in the dialog box, but doing so would reopen bug 444440. As I'm not familiar with the Firefox codebase, I didn't go as far as trying to write a patch that would solve both bugs, but ideally that's what would be needed here.

Changed in firefox:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Mike?

Revision history for this message
In , Ritesh Khadgaray (khadgaray) wrote :

This seems to be a bug with gio handler

NS_IMETHODIMP
nsMIMEInfoUnix::GetHasDefaultHandler(bool *_retval)
{
...

  *_retval = false;
  nsRefPtr<nsMIMEInfoBase> mimeInfo = nsGNOMERegistry::GetFromType(mSchemeOrType);
<--- we check for mime type, and not for protocol handler. The older code always would fall back to protocol handler based of mailcap.

  We need to fix GetFromType(mSchemeOrType), to handle scheme ( protocol).

This is seen from here

NS_IMETHODIMP
nsGIOService::GetAppForMimeType(const nsACString& aMimeType,
                                nsIGIOMimeApp** aApp)
{
...
  GAppInfo *app_info = g_app_info_get_default_for_type(content_type, false);
...
<-- We probably need to add g_app_info_get_default_for_uri_scheme () , if app_info is null.

untested though .

Revision history for this message
In , Josh Matthews (joshmatthews) wrote :

Ritesh, do you want to test your idea? https://developer.mozilla.org/en/Simple_Firefox_build should get you started, if you don't already have a local build.

Revision history for this message
In , Ritesh Khadgaray (khadgaray) wrote :

This indeed is the issue. Initial "patch" . Will post the final patch in a while ( rebuilding is a sloow process ).

--- a/uriloader/exthandler/unix/nsGNOMERegistry.cpp 2014-02-24 23:38:31.303287298 +0530
+++ b/uriloader/exthandler/unix/nsGNOMERegistry.cpp 2014-02-25 00:04:12.643350922 +0530
@@ -148,7 +148,12 @@ nsGNOMERegistry::GetFromType(const nsACS
     nsCOMPtr<nsIGIOMimeApp> gioHandlerApp;
     if (NS_FAILED(giovfs->GetAppForMimeType(aMIMEType, getter_AddRefs(gioHandlerApp))) ||
         !gioHandlerApp) {
- return nullptr;
+ // Unable to find mime handler, probably a protocol. moz bz#947868
+ // Need a better way to identify if this is a scheme - check for nsMIMEInfoBase::eProtocolInfo ?
+ if (NS_FAILED(giovfs->GetAppForURIScheme(aMIMEType, getter_AddRefs(gioHandlerApp))) ||
+ !gioHandlerApp) {
+ return nullptr;
+ }
     }
     gioHandlerApp->GetName(name);
     giovfs->GetDescriptionForMimeType(aMIMEType, description);

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.