FF 4 requires both .desktop and gconf entries for url handlers

Bug #727372 reported by dobey on 2011-03-01
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox (Ubuntu)
High
Chris Coulson
Natty
High
Chris Coulson

Bug Description

Binary package hint: firefox

It seems as though FF4 is requiring that both the old style gconf entries, and the new .desktop file x-scheme-handler mime types be registered for handling additional URI schemes. This is broken and it should only use the glib API for opening the handler for the mime type.

dobey (dobey) on 2011-03-01
Changed in firefox (Ubuntu):
assignee: nobody → Chris Coulson (chrisccoulson)
affects: firefox (Ubuntu) → ubuntu
affects: Ubuntu Natty → firefox (Ubuntu Natty)
Changed in firefox (Ubuntu Natty):
importance: Undecided → High
status: New → Triaged
Chris Coulson (chrisccoulson) wrote :

This seems to be a consequence of nsGNOMERegistry::HandlerExists checking that a handler exists using the old gconf values (which it shouldn't be doing now), before doing the actual launch in nsGNOMERegistry::LoadURL using gio (which works correctly if it ever gets to that stage).

Should be a fairly trivial fix

Chris Coulson (chrisccoulson) wrote :

Will try and get this ready for the RC1 release this week

Changed in firefox (Ubuntu Natty):
milestone: none → ubuntu-11.04-beta-1
status: Triaged → In Progress

Created attachment 517395
Use GIO for finding the default handler

We're trying to get u1ms:// URI's to open in Banshee in Ubuntu, and have registered the handler in the proper way (it's desktop file defines x-scheme-handler/u1ms in its MimeType field). However, clicking u1ms links in Firefox results in a dialog with the following message being displayed:

"Firefox doesn't know how to open this address, because the protocol (u1ms) isn't associated with any program."

(Note, that we're building Firefox with --enable-gio in Ubuntu, as this doesn't work in gnomevfs at all anymore)

This is because nsGNOMERegistry::HandlerExists checks for the existence of a protocol handler by looking directly at the GConf keys in /desktop/gnome/url-handlers, which are deprecated in GNOME 3.0 (see also bug 611953). When built with --enable-gio, nsGNOMERegistry::HandlerExists should use the gio API directly.

Note, this bug applies to any URI which needs to be handled by an external application (eg, mailto:// links only work on my machine by virtue of having stale entries in /desktop/gnome/url-handlers, and those don't match my preferred mail client anyway).

I've attached a patch which fixes this. Unfortunately, it depends on the patches on bug 611953 too, as it uses the new nsIGIOService::GetAppForURIScheme

Changed in firefox:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in firefox (Ubuntu Natty):
milestone: ubuntu-11.04-beta-1 → ubuntu-11.04-beta-2

Comment on attachment 517395
Use GIO for finding the default handler

nsGIOService::Init() always returns true, so IIUC the presence of NS_GIOSERVICE_CONTRACTID indicates the presence of GIO but not necessarily GVFS.
Would it be reasonable to fall back to GConf if nsIGIOService::GetAppForURIScheme failed?

(In reply to comment #1)
> Comment on attachment 517395 [details]
> Use GIO for finding the default handler
>
> nsGIOService::Init() always returns true, so IIUC the presence of
> NS_GIOSERVICE_CONTRACTID indicates the presence of GIO but not necessarily
> GVFS.
> Would it be reasonable to fall back to GConf if
> nsIGIOService::GetAppForURIScheme failed?

I don't think we need to do that. With glib >= 2.28, nsIGIOService::GetAppForURIScheme will work regardless of whether gvfs is present (g_app_info_get_default_for_uri_scheme is implemented independently of the vfs backend).

On older glib versions this was delegated to a gvfs module (which just did the lookup in the legacy gconf settings). If gvfs is missing in this case, falling back to gconf to do the lookup won't help much. Launching will fail straight afterwards even if we do find the handler, as the launch is already done via GIO (with no fallback) and depends on gvfs being present (glib < 2.28)

Comment on attachment 517395
Use GIO for finding the default handler

(In reply to comment #2)
> Launching will fail straight
> afterwards even if we do find the handler, as the launch is already done via
> GIO (with no fallback) and depends on gvfs being present (glib < 2.28)

OK. There's nothing to lose then.

>+ if (NS_FAILED(giovfs->GetAppForURIScheme(nsDependentCString(aProtocolScheme),
>+ getter_AddRefs(app))))

Can you align the "getter_AddRefs(app))" argument with the first argument of the function call, please?

Created attachment 525655
Use GIO for finding the default handler (v2)

Thanks, I've fixed the indentation now

Comment on attachment 525655
Use GIO for finding the default handler (v2)

>+ if (NS_FAILED(giovfs->GetAppForURIScheme(nsDependentCString(aProtocolScheme),
>+ getter_AddRefs(app))))

"getter_AddRefs(app)" is not a parameter to NS_FAILED() but to GetAppForURIScheme() so it should be aligned with "nsDependentCString(aProtocolScheme)".

Created attachment 525691
Use GIO for finding the default handler (v3)

Oops, yes you're right, sorry. Here we go again :)

Changed in firefox (Ubuntu Natty):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package firefox - 4.0+nobinonly-0ubuntu2

---------------
firefox (4.0+nobinonly-0ubuntu2) natty; urgency=low

  * Update globalmenu-extension to 1.0.1
    - Fixes LP: #749450 - bookmarks editor doesn't work properly

  * Added Spanish and Japanese translations for static quicklist entry
    - update debian/firefox-*.desktop.in
  * Fix LP: #727372 - URI handling is broken. Use GIO for checking if
    a particular URI scheme has a handler, rather than probing GConf
    - add debian/patches/default-uri-handler-check-use-gio.patch
    - update debian/patches/series
 -- Chris Coulson <email address hidden> Sat, 16 Apr 2011 23:21:03 +0100

Changed in firefox (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in firefox:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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