API for supporting choice of URN or protocol handlers, including 'urn' attribute

NEW
Unassigned

Status

()

P5
enhancement
9 years ago
4 months ago

People

(Reporter: brettz9, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2) Gecko/20100105 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: 

The ability to use nsIProtocolHandler is a very powerful and interesting feature. I'm currently using it to allow links to Unicode characters in one of my extensions.

My extension's special links aim to find Unicode characters and show them in context in a chart in my extension links to be used at my own site, but since I do not want to limit myself or my users to web-based protocol handlers, I'm currently using the interface nsIProtocolHandler and it works rather well (though I'm not quite sure about the distinction between whether this would be better considered as a URN rather than a protocol).

Another extension at https://addons.mozilla.org/en-US/firefox/addon/1940 offers URN support, but, as nice as it is, this depends on having installed the extension and does not offer an API for other extensions to add themselves as potential handlers.

On a related note, I think there is great, apparently unrecognized, potential for Microsoft's URN attribute: http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx . This may even have more potential than protocol handlers in that websites do not need to commit themselves to a link which leads nowhere if the handler is not installed--it can still go to its href target--at least if the urn attribute does not get picked up. I might think that even JavaScript could be added into the mix, allowing for dialogs, etc., if urn support is not detected.

I'd like to see extensions have the ability to register themselves as _alternate_ protocol handlers or URN handlers, so that the user interface could query to find the current default handler in preferences (as well as default preferences perhaps as to whether to use 'href' over 'urn', or vice versa, and dependent on any JavaScript). Ideally, the API would also allow applications, such as a context menu overlay, to iterate through the potential protocols/URN handlers so one could choose which one to activate, as well as be able to trigger a particular non-default one.

If Wikipedia, for example, used the "urn" attribute on ISBN numbers, there would be a formal way for applications to register themselves to handle those links, even while the default behavior of such links (i.e., the 'href' attribute) would lead to the wiki page for that ISBN. Some sites might wish to add a JavaScript handler which allowed the user to be told the first time they click on such a link, for example, that the links allowed for other URN handling applications to handle the data. Similarly, sites (e.g., Wikipedia) could add URNs for person's names, addresses, etc., without committing to particular services, except by default.

Thank you!

Reproducible: Always
(Reporter)

Comment 1

9 years ago
Akin to my proposal for centralized font retrieval (Bug 512619), I think it would be ideal to also have the ability to query a central server for extensions (e.g., those hosted at AMO with a special install.rdf field or the like) to find out other extensions which could support the protocol/URN
Valid enhancement request, nonstandard attribute (though I agree potentially interesting), confirming and moving.
Status: UNCONFIRMED → NEW
Component: General → DOM: Core & HTML
Ever confirmed: true
OS: Windows Vista → All
QA Contact: general → general
Hardware: x86 → All
(Reporter)

Comment 3

9 years ago
I should clarify/revise the original comment now that I have a somewhat better idea about protocols and this concept.

The built-in protocol infrastructure already seems adequate.

And I no longer believe IE's proprietary URN attribute on <a/> is the ideal solution, since it is limited to URNs.

I offered my proposal to HTML5 but was advised to make an extension and gain experience with the possibility.

So I've created an extension (at https://addons.mozilla.org/en-US/firefox/addon/162154/ ) to propose two new attributes to <a/> to better support urn: and other protocols: @uris and @alternateURIs.

The "uris" attribute will be checked before "href" to give priority to trying out some protocols (in order) which may be less supported than HTTP/S (e.g., xmpp: or urn:). If this white-space-separated list of URIs fails, it will default to 'href'. The advantage of this approach in my view is that it should foster experimentation with protocols and URNs, since a link can be made to actually do something useful for those who cannot activate the protocol whether due to a legacy browser or due to a protocol not having a handler. For fallbacks, one can thus either link to another page or perhaps use javascript: to provide an alert about what the user can do to add support for the protocol. Currently, if you use href for URN or other protocols and the protocol is not supported, one may just get a generic message in Firefox about the protocol not being supported.

The "alternateURIs" attribute, on the other hand, is intended for those who wish to give priority to the "href" value, but who wish to make it convenient to offer the user access to alternative URIs via right-click. For example, if Wikipedia used a link to a book to lead to its own page about that book by default, it could still also allow right-clicks on the link to trigger a more generic urn:isbn link (while another site might wish to link to specific alternative sites like Amazon, Barnes & Noble, etc.). The extension currently allows distinctive custom coloring of these attributes when used in a page, so that the user can be made aware of further resources embedded in the link (i.e., so they can right-click to find more alternatives for that link).

The extension linked to above supports the attributes in question, though of course the idea is to get it supported in Firefox by default and across browsers. The extension also borrows from the extension "URN Support" (at https://addons.mozilla.org/en-US/firefox/addon/1940 ) in offering special handling of URNs by default, as well as offering the ability to write a custom handler in JavaScript (for advanced users).
(Reporter)

Comment 4

8 years ago
The extension at https://addons.mozilla.org/en-US/firefox/addon/162154/ has now been approved by the review team.

I might add that this idea could be greatly enhanced if there could be a central database to check for applications or extensions which supported a given URN/protocol.
(Reporter)

Comment 5

8 years ago
Cross-referencing to a similar bug, Bug 440620 which proposes JavaScript mechanisms, while my bug (though also mentioning JS mechanisms, also focuses on markup).
I think we should WONTFIX this. Making something as fundamental as linking dependent on browser-specific extensions seems like a terrible idea. (And URNs have flopped anyway.)
(Reporter)

Comment 7

6 years ago
With a fallback, what is the harm in this? Custom protocols are already possible, but this will allow a regular fallback...
(Reporter)

Comment 8

6 years ago
Please see Comment 3 as the point is that it WON'T be dependent on browser-specific extensions or custom website extensions. It can fall-back to a normal website...
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.