Closed Bug 389632 Opened 14 years ago Closed 14 years ago

nsExternalHelperAppService::ExternalProtocolHandlerExists (almost) always sets aHandlerExists to PR_TRUE enabling gnomevfs protocols

Categories

(Core Graveyard :: File Handling, defect)

x86
Linux
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9alpha7

People

(Reporter: karlt, Assigned: karlt)

References

Details

Attachments

(1 file, 4 obsolete files)

gnomevfs protocols are restricted in nsGnomeVFSProtocolHandler to disable all but trusted protocols.

However, nsOSHelperAppService::LoadUriInternal invokes gnome_url_show through nsGNOMERegistry::LoadURL.  gnome_url_show invokes gnome_vfs_url_show.

gnome_vfs_url_show uses gconf /desktop/gnome/url-handlers if a handler is found, but otherwise falls back to gnomevfs modules.  If the url is file:* or if there is an application for the mime type with %U or %u in the Exec desktop field, then that application is invoked.

nsOSHelperAppService::OSProtocolHandlerExists checks whether there is a gconf /desktop/gnome/url-handlers entry but now that the result of this check is ignored, gnome_vfs_url_show can fall back to gnomevfs.

This probably started after the commit from bug #388701.

It looks like nsOSHelperAppService::GetProtocolInfoFromOS should check exists from OSProtocolHandlerExists.

gnome-vfs issues probably won't exist on other platforms but other platforms may be affected in other ways as they also ignore check in nsOSHelperAppService::GetProtocolInfoFromOS.
OK, the answer is "apparently not"
(In reply to comment #1)

No.  *aHandlerInfo from GetProtocolInfoFromOS is (almost) always non-NULL.


(os2 doesn't have GetProtocolInfoFromOS)
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Flags: blocking1.9?
Attachment #274092 - Flags: review?(dmose)
Attached patch comments with extra word removed (obsolete) — Splinter Review
Attachment #274092 - Attachment is obsolete: true
Attachment #274094 - Flags: review?(dmose)
Attachment #274092 - Flags: review?(dmose)
Comment on attachment 274094 [details] [diff] [review]
comments with extra word removed

r+sr=dmose; it'd be great if you could paste the same comment into the unix version of GetProtocolInfoFromOS() too.
Attachment #274094 - Flags: review?(dmose) → review+
Attachment #274100 - Flags: review?(dmose)
Comment on attachment 274100 [details] [diff] [review]
comments for GetProtocolInfoFromOS

r+sr=dmose
Attachment #274100 - Flags: review?(dmose) → review+
Attachment #274071 - Flags: approval1.8.1.7?
Attachment #274094 - Flags: approval1.8.1.7?
Attachment #274100 - Flags: approval1.8.1.7?
Attachment #274071 - Flags: approval1.8.1.7?
Attachment #274094 - Flags: approval1.8.1.7?
Attachment #274100 - Flags: approval1.8.1.7?
a=roc for M7
Target Milestone: --- → M7
Target Milestone: M7 → mozilla1.9beta1
Attachment #274071 - Attachment is obsolete: true
Attachment #274094 - Attachment is obsolete: true
Attachment #274100 - Attachment is obsolete: true
Blocks: 389866
Tested patch on windows debug build and filed bug 389866 as a follow on.
Merged patch checked in; thanks Karl!

Checking in exthandler/nsExternalProtocolHandler.cpp;
/cvsroot/mozilla/uriloader/exthandler/nsExternalProtocolHandler.cpp,v  <--  nsExternalProtocolHandler.cpp
new revision: 1.44; previous revision: 1.43
done
Checking in exthandler/beos/nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/beos/nsOSHelperAppService.cpp,v  <--  nsOSHelperAppService.cpp
new revision: 1.23; previous revision: 1.22
done
Checking in exthandler/mac/nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/mac/nsOSHelperAppService.cpp,v  <--  nsOSHelperAppService.cpp
new revision: 1.53; previous revision: 1.52
done
Checking in exthandler/unix/nsGNOMERegistry.cpp;
/cvsroot/mozilla/uriloader/exthandler/unix/nsGNOMERegistry.cpp,v  <--  nsGNOMERegistry.cpp
new revision: 1.16; previous revision: 1.15
done
Checking in exthandler/unix/nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp,v  <--  nsOSHelperAppService.cpp
new revision: 1.70; previous revision: 1.69
done
Checking in exthandler/win/nsOSHelperAppService.cpp;
/cvsroot/mozilla/uriloader/exthandler/win/nsOSHelperAppService.cpp,v  <--  nsOSHelperAppService.cpp
new revision: 1.74; previous revision: 1.73
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 389969
I think we want this on the 1.8 branch as well, for bug 389611
Flags: blocking1.8.1.7?
Daniel,

This bug was only a regression since bug #388701 on trunk, so this shouldn't be needed on the branch.

biesi commented similarly on irc around 2007-07-26 19:19:00 PDT.
Flags: blocking1.8.1.7?
Target Milestone: mozilla1.9 M8 → M1
(Correcting milestone accidental change: maybe I shouldn't reload bugzilla pages.)
Target Milestone: M1 → mozilla1.9 M7
marking blocking minus for the branches to put the relevant information up top for the next guy who follows the dependency chain
Flags: wanted1.8.1.x-
Flags: wanted1.8.0.x-
Flags: blocking1.8.1.7-
Flags: blocking1.9?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.