Closed
Bug 639467
Opened 13 years ago
Closed 13 years ago
External URI handling broken due to protocol handler registration changes
Categories
(Core Graveyard :: File Handling, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla6
People
(Reporter: chrisccoulson, Assigned: chrisccoulson)
References
Details
Attachments
(1 file, 2 obsolete files)
3.54 KB,
patch
|
Details | Diff | Splinter Review |
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
Assignee | ||
Updated•13 years ago
|
See Also: → https://launchpad.net/bugs/727372
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → chrisccoulson
Assignee | ||
Updated•13 years ago
|
Attachment #517395 -
Flags: review?(roc)
Attachment #517395 -
Flags: review?(roc) → review?(karlt)
Comment 1•13 years ago
|
||
Comment on attachment 517395 [details] [diff] [review] 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?
Assignee | ||
Comment 2•13 years ago
|
||
(In reply to comment #1) > Comment on attachment 517395 [details] [diff] [review] > 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 3•13 years ago
|
||
Comment on attachment 517395 [details] [diff] [review] 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?
Attachment #517395 -
Flags: review?(karlt) → review+
Assignee | ||
Comment 4•13 years ago
|
||
Thanks, I've fixed the indentation now
Attachment #517395 -
Attachment is obsolete: true
Attachment #525655 -
Flags: review+
Assignee | ||
Updated•13 years ago
|
Attachment #525655 -
Flags: review+ → review?
Assignee | ||
Updated•13 years ago
|
Attachment #525655 -
Flags: review?
Comment 5•13 years ago
|
||
Comment on attachment 525655 [details] [diff] [review] 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)".
Assignee | ||
Comment 6•13 years ago
|
||
Oops, yes you're right, sorry. Here we go again :)
Attachment #525655 -
Attachment is obsolete: true
Comment 7•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/46a89f1c9263
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•