Protocol handlers are a new feature in Firefox 3.5 that allows links like mailto:email@example.com to be handled by a webmail application. In order to do that, the site needs to support a special API described on http://developer.mozilla.org/en/docs/Web-based_protocol_handlers. For en-US, we're currently shipping with GMail and Yahoo! Mail for mailto: and 30boxes for webcal: urls, and we're on a ongoing evangelism effort to add more. We're going to add support for irc links to mibbit.com soon. For English (South Africa), we'd like to do that, too. First, the localization team and Stas (Stas Malolepszy) will look at the market for the language and come up with a good candidates. Dwayne, we'll need your input on this, the guidelines for making recommendations are on http://wiki.mozilla.org/Firefox_web_services_guidelines. Following that is a reach out by the evangelism team to try to get the vendor to support protocol handlers. Once that happens, Stas will take over in reviewing the actual implementation, which will need to change the gecko.handlerService.* entries in en-ZA/browser/chrome/browser-region/region.properties. Please don't make changes to that file without getting a positive review by Stas or somebody else appointed by Stas/Sethb on a patch for that change upfront.
I am asking on a few channels in ZA: Seems we have some that I will need to research further: 1) webmail.co.za - website is accesible 2) MTN - cellphone provider, trying to find the website 3) Vodamail - possibly through http://www.vodacom.co.za/vodacom4me/login.jsp
Thanks, Dwayne. These look interesting. Any further research? Does MTN provide a webmail service? And, what is the size of the user base for Vodamail? Perhaps we can look at the market size of each service to determine what is best? We'll defer to your recommendation and judgment. Let us know what you think.
In the past I've seen an MTN webmail service. But I've had no success in finding any of these or their market share. I might try something more direct by trying to source IT people within these organisations.
MTN: * Fastmail - http://www.mtnfastmail.com/uwc/auth - seems to be for MTN Nigeria though * I-Mail - http://www.mtnsp.co.za/default.aspx?pid=195 - this seems like the correct point Market share is unclear, as in how many people actually use these services.
MTN: Seems they have both I-Mail and MTN Loaded: https://mail.mtnloaded.co.za/mail/login.php
So, do I understand correctly that there are 3 candidates, one if which offers 3 different web-based email services (MTN)? I'd like to reach out to them and ask if they support protocol handlers. Here is some contact information that I found, could you please verify it's OK? http://www.webmail.co.za/default.aspx?link=site_contact Email: firstname.lastname@example.org/ email@example.com http://www.vodacom.co.za/about/contact_info_email_us.jsp Contact form. https://mail.mtnloaded.co.za/mail/mtnloaded_extra.php E-mail address: firstname.lastname@example.org http://www.mtnsp.co.za/Support/ContactUs/Pages/ContactUs.aspx Cell phone number required to do anything. http://www.mtnsp.co.za/default.aspx?pid=195 Gives me 404. http://www.mtnfastmail.com/uwc/auth No contact info.
(In reply to comment #6) > I'd like to reach out to them and ask if they support protocol handlers. Here > is some contact information that I found, could you please verify it's OK? All of those look good to me. Hopefully a contact with MTN will give a single point contact that can help with all the variants.
Stas: Any response from the contacts you've listed above?
@stas: any movement here? Should we change this to be non-blocking for an en-ZA maybe and then we can get these as they slowly come through?
Hey guys, This haven't been touched in 2 years now, and I'd like us to go over this again, as this is really must-have. Dwayne, did something change on this front, or you still see services from comment 6 as best candidates? If latter, should I contact them, or you will do it? P.S. If you talk to them, or already did, please forward any conversation to me, so that we have it on file.
Summary: [en-ZA] Firefox 3.5 protocol handler setup for English (South Africa) → [en-ZA] Firefox protocol handler setup for English (South Africa)
I've read through all the docs and I'm still a bit lost as to what exactly this feature is. Is it about integrating this within the en-ZA Firefox so that it understands that e.g. webmail.co.za could be used for mail. Or is it about sites like webmail.co.za being able to tell Firefox that they can be used for email. My guess is both but I seem to be getting a bit confused.
Stas re comment 10, I've had a quick look and the only definite seems to be webmail.co.za. Those related to vodacom and MTN are worth pursuing but I'm not sure how easy it will be to find the correct person. I can follow these up as soon as I have some clarity on what exactly is involved for them and the benefits to them.
It's about handling mailto: and webcal: urls. For mailto:, http://people.mozilla.org/~ctalbert/ is a pretty good test suite. The sites wouldn't need to implement the DOM api, we just need a URL for their service, and that URL should pass the suite above, at least for mailto:. For webcal, the service should display the calendar, if possible also for unsubscribed users. Additional features for subscribed users is fine, of course.
(In reply to Dwayne Bailey from comment #12) > Stas re comment 10, I've had a quick look and the only definite seems to be > webmail.co.za. Those related to vodacom and MTN are worth pursuing but I'm > not sure how easy it will be to find the correct person. > > I can follow these up as soon as I have some clarity on what exactly is > involved for them and the benefits to them. Does this mean that en-ZA users are more likely to use webmail.co.za instead of gmail/yahoomail? So, this isn't about providing anything that's local, but finding the best option for users in a given locale. As for what protocol handlers are used for: We're using protocol handlers when one types in an address in Firefox location bar that represents transmitting data over given protocols(currently mailto, webcal, irc and ircs). So, what should happen is that, if a one doesn't have a system wide recognized protocol handler(ie. thunderbird for mailto) that's already associated with, the OS should ask you how do you wanna handle that link, and what you chose in protocol handlers should appear as one option. Let me give you 2 examples: On my mac, I have both email and IRC clients installed. Now, thunderbird is set up as a default system client for handling email, where Textual(IRC client) isn't set up as a handler for irc:// like links. Now, when I type in mailto:email@example.com in Firefox, my OS knows I wanna send email, and will use Thunderbird for that(opens a new compose window). On the other hand, if I type in irc://something.com, which should open up a new IRC server, my system doesn't know how to open it, so it pops up a selection dialogue asking me how do I want to handle that, giving me 2 options: 1) pick your own app 2) use webchat client, Mibbit, which is the default protocol handler in Firefox for these type of links  Hope this helps.  http://screencast.com/t/d1TsAnVatmec
Thanks to both of you that was really helpful. (In reply to Milos Dinic [:Milos] from comment #15) > Does this mean that en-ZA users are more likely to use webmail.co.za instead > of gmail/yahoomail? So, this isn't about providing anything that's local, > but finding the best option for users in a given locale. So then the simple answer is everyone uses Gmail if they are using any web based mail. They're very unlikely to use Yahoo, but it can't hurt. They are more likely to use something from Microsoft but any users I'd think are very small compared to Gmail. The others I mentioned are just not options for this. They would be candidates for evangelism to get their systems able to register themselves as protocol handlers. In terms of irc - that looks good. In terms of ical - more likely that people use Google Calendar if they use anything online. I don't see it in en-US so not sure if it is an option. The summary seems to be go with the en-US defaults unless we can/want to change stuff around Microsoft for email and Google for cal.
(In reply to Dwayne Bailey from comment #16) > The summary seems to be go with the en-US defaults unless we can/want to > change stuff around Microsoft for email and Google for cal. I'm not sure what our options are regarding Google Calendar, so I'll leave that for Axel. As for the Microsoft thing, are you referring to Hotmail/MSN? If so, I'd rather go with gmail, given the usability/number of ads on Hotmail/MSN. Axel, any feedback?
IIRC, we went for 30boxes because they give you something without having an account on there, I don't recall what google does.
OK, so we stay with 30boxes then and Hotmail/MSN is not an options so stay with gmail.
Dwayne, everything is almost in place. Now, do you want to have Google and My Yahoo! as feed handlers, respectively, just as in en-US defaults? If so, please create a patch for fixing that and flag me for a review.
Created attachment 643334 [details] [diff] [review] Changes to region.properties This is an en-US copy over: What's included: * Copyright heeader updated * Bing added to browser.search.order - since we added Bing to the search engines I thought that was correct. We've dropped Yahoo but I assume having it here won't break anything. * Feed handlers changed * browser.search.siteSearchURL - changed to use https
Comment on attachment 643334 [details] [diff] [review] Changes to region.properties Review of attachment 643334 [details] [diff] [review]: ----------------------------------------------------------------- Yes, this looks good. Please wait for Axel's feedback and then push the changes adding this bug and summary in commit message, along with r=milos. Thanks!
Fixed in changeset b91cbaffc301
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.