Web protocol handlers are a new Firefox 3 feature that gives more power to RIA web applications. Basically, when a user clicks on a link with specific protocol, Firefox can send an HTTP(S) request with the link data to a web application. An easy example is a mailto: link:
Web Master
Normally, if a user clicks this link, Firefox (or other browser) will open the default mail application on the user’s machine and start composing an email message. With so many web-based email applications in use today, it only seems natural that some people would want to use a web-based email application to compose the message.
With web protocol handlers, the web application can register the specific protocol it wants to handle. Firefox will then prompt the user to choose which of the registered applications (web or desktop) it should use to handle the action. Any protocol, real or imaginary, can be used – mailto: is only one example, webcal:, tel: and fax: are others. In the case of the mailto: example, the web-based email application could parse the data passed to it from Firefox to get the parameters of the protocol, perform a sign-on (if needed) and display its “compose” UI.
Firefox 3 will ship with some packaged web protocol handlers. For those developers interested in adding protocol support to their web applications, we have an MDC article explaining the details of setting up and using web protocol handlers. Also checkout the compliance test page we use to test the feature. During the process of getting the packaged handlers into Firefox 3, we ran into some common implementation misconceptions:
- Web protocol handlers are not just for
mailto:! The system is designed for any protocol. - Web protocol handlers have no idea about the protocol details. For example, the system does not know that
mailto:support to or subject parameters. The system just sends the entire HREF of the link to the registered handler. Be prepared to do the parsing yourself.
Go forth and make web applications rock!
Would it be possible for a site to figure out if the user have a handler set up for a specific protocol? E.g. a useful protocol (to have standardized) would perhaps be a “blog:” handler, that could replace the multitude of “blog this”-icons/buttons. But if the user doesn’t have a handler set up, the site might want to fall back to the list of buttons (although then they will show the long list of icons, to the users that persuasively need it the least, hmm), so it might be use full for the site to be able to detect if the users browser can handle a specific protocol before showing the link (just as it might be useful for a site to be able to detect if the users browser can handle a “bittorrent:” protocol, such that that protocol should transparently be used if recognized).
Also it would probably help to bootstrap the process if the browser would show a list of suggested sites that could handle the url, if the user don’t already have a handler installed for a given protocol. It seems to me that much the same process used for registering/filtering/verifying addons could be used for protocol handlers.
Hey! This works really great! I was thinking there might be some issues with Mac OS X (10.4.11) Mail, but it worked really well. I am looking forward to experimenting with this.
There are a few glitches that I see in the test compliance page with the nightly app from 4/28 (trunk) and if you can let me know what component to file and look for bugs in, I would be appreciative. Thanks!
I can see where you would want to do this with a browser extension, but I can’t see its place in web-apps.
Can you give a specific example where this could be desirable?
I can’t imagine wanting the web-site I’m visiting to take over my sending of an email. Same goes for the other suggestions here.
Ummmm…Sean Hogan: What if the website is GMail. Or Yahoo Mail?
You could register gmail and yahoo mail with your browser. Then, when you are browsing SOME OTHER site (that’s the important bit) the browser will ask you whether you want to open mailto links in Gmail or Yahoo.
Sean:
But, that’s the whole point. If you’re a user of Gmail/Hotmail/YahooMail, you’re already sending and receiving email through your provider. With web protocol handlers, you can now click on mailto: links in existing web pages, and start composing a message in your webmail account (instead of in a desktop mail application like Exchange or Thunderbird).
That’s not to say any random site can take over your email. A user has to explicitly allow installing the protocol handler, and then select it to actually use it.
This is really cool thing. More than the concept I am fascinated by the explanation. Clear, simple and straight forward. I guess this will be of great help to me.
Thank you mfinkle.
Justin:
Thanks for the clarification. I was reading it as enabling a web-page to register protocol handlers for links occurring within the same page (or domain).
Mark, great explanations, thanks!
nitpicking: “sends the enitre HREF” -> “sends the entire HREF”
I completely agree with what AndersH said. The site should have some means to determine whether a protocol is registered _before_ the site hands the corresponding link(s) to Firefox 3.
See http://fghi.pp.ru/?area://Ru.Blog.Mithgol/ for example. If an area:// protocol is registered, all those http://fghi.pp.ru/?area://Ru.Blog.Mithgol/… links could be just area://Ru.Blog.Mithgol/… links, bit the site right now may not know whether they are safe.