[ This bug is one of the recommendations in the W3C's "Common User Agent Problems" document, URL above. One bug has been filed on each recommendation, for deciding whether we do it and, if not, whether we should. ] 1.5 Allow the user to add new URI schemes in a straightforward way. For instance, allow users to associate external programs with URI schemes. The user agent should inform the user when it does not recognize a URI scheme in content. Example: A user may want the "tel" scheme (e.g., tel:+33-4-12-34) to interact with their telephone. Or they may want the "irc" scheme (e.g., irc://irc.example.org/) to activate an IRC client on their desktop with a connection to the specified server. Wrong: Some user agents ignore the scheme part (before the ":") when the scheme is unknown to them, interpret the colon character as though it were encoded as '%3A' and then treat the URI as though it were a relative URI, usually producing a broken link (and confusing users).
This bug basically means "Protozilla". :-) Gerv
This should be done in the `Applications' category of preferences -- instead of specifying a MIME type, you specify a protocol. See, for example, the `Helper Apps' section in the Internet control panel on Mac OS.
Hardware: PC → All
See also bug 11459 -- using an external client for mailto: bug 34819 -- altmail support bug 37637 -- support the tel: and sip: protocols bug 44317 -- support the dict: protocol bug 56478 -- another mailto: report Protozilla (http://protozilla.mozdev.org/) is already written; moving it into the codebase and integrating its UI into the Preferences panel would solve these bugs/feature requests, and future requests of this type. Note that the alternate-mail and telnet registration are 4xp bugs, and that registration of additional URI schemes is a "3xp" bug.
see also bug 2110
see also bug 2110
Summary: W3C CUAP: Allow registration of new URI schemes → [RFE]W3C CUAP: Allow registration of new URI schemes
This bug depends on newly created bug 68702, which is a request to implement inter-process communication (IPC) in Mozilla. A separate bug is needed for that feature of Protozilla because it is architecturally distinct from the rest of Protozilla. Although one can use Protozilla without IPC, it will limit many of its features, such as using client-side CGI to implement protocol handlers. cc'ing firstname.lastname@example.org per his request
Security issues: Launching helper applications or running CGI scripts to handle new URI schemes raises several security concerns. Although Protozilla, the candidate code for implementing the new URI schemes, is designed with security in mind, independent reviewers are needed to carefully check the design and implementation of Protozilla. Any volunteers?
Depends on: ipc
*** Bug 73003 has been marked as a duplicate of this bug. ***
*** Bug 68962 has been marked as a duplicate of this bug. ***
mass move, v2. qa to me.
QA Contact: tever → benc
Some RFCs have recently been published defining URN schemes for bibliographic references: http://www.faqs.org/rfcs/rfc3187.html RFC for ISBN URNs http://www.faqs.org/rfcs/rfc3188.html RFC for National Bibliography Number URNs It would be neat if Mozilla had some way to support them, like by translating them into query URLs to a site where you could look up information on books -- if it's something like amazon.com, it could even be a revenue source for the Mozilla project if it had a referral ID embedded. The ideal, of course, would be for there to be a configurable setting in Mozilla to allow various URI / URL / URN schemes to be mapped at the user's option to either a query URL (with the content segments of the URI inserted at configurable places), a launching of a helper application, etc. For instance, somebody might want to have URNs like "urn:isbn:1-2345-67890" translated to "http://www.somesite.example/cgi-bin/isbn.pl?search=1-2345-67890". This stuff is pretty minor in terms of actual likely use by normal Web users, but it's the sort of thing that would help give Mozilla a reputation within the computer geek community of being at the leading edge in supporting standards regarding information structure (as opposed to eye candy).
*** Bug 82776 has been marked as a duplicate of this bug. ***
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Summary: [RFE]W3C CUAP: Allow registration of new URI schemes → W3C CUAP: Allow registration of new URI schemes
Don't we do this now? What does: network.protocol-handler.external.<scheme> do?
Assignee: new-network-bugs → darin
*** Bug 202715 has been marked as a duplicate of this bug. ***
16 years ago
i agree with benc. this bug as originally posed seems to be solved. it does not require protozilla. marking WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 16 years ago
No longer depends on: ipc
Resolution: --- → WORKSFORME
I believe the 'WorksForMe' resolution is incorrect, or if not incorrect, then there is inadequate documentation in this bug to tell me why. Darin Fisher apparently resolved this based on comment 18. However, I have added network.protocol-handler.external.irc to my prefs.js (in an install that does not include Chatzilla) but entering an 'irc:' URI into the address bar gets me "irc is not a registered protocol." Also, displaying a message containing an irc: URI in the MailNews program does not linkify that string.
you have to set network.protocol-handler.app.irc to the full path to the application you want to use. This will work on unix/linux only though. For Windows and MacOS, just register your protocol as a system-wide protocol handler. Here's the checkin comment that should explain this a bit: "This allows setting external protocol handlers via a preference setting: network.protocol-handler.app.<scheme> This is supposed to be a string value. Mozilla will first try to interpret this as an absolute path, then as a filename relative to $MOZILLA_FIVE_HOME, then as a file in $PATH. If an application is found in one of these places, it will be called and passed the complete url as first (and only) argument."
Christian Biesinger wrote: > "This allows setting external protocol handlers via a preference setting: > network.protocol-handler.app.<scheme> I added user_pref("network.protocol-handler.app.mailto", "/tmp/foo"); to user.js, restarted mozilla, and clicking on mailto links still gives me "mailto is not a registered protocol" (in a Mozilla that does not have Communicator.) Is this in fact believed to work on Linux? In what version? Mozilla 1.5 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031031
1.5 is too old. I can't remember if 1.6alpha is new enough; 1.6beta will definitely have it, as do current nightlies.
For the benefit of any Unix users who might stumble across this bug -- I have updated my "gsendmail" program ("http://www.jwz.org/gsendmail/") to work with Mozilla 1.6b. By adding this to user.js: user_pref("network.protocol-handler.external.mailto", "true"); user_pref("network.protocol-handler.app.mailto", "gsendmail"); you can have a simple GUI mail-composition window pop up when you click on mailto: URLs even if you don't have the full Confusicator suite installed.
> user_pref("network.protocol-handler.external.mailto", "true"); hm, it works with the "true" in quotes?
You need to log in before you can comment on or make changes to this bug.