Closed Bug 413630 Opened 17 years ago Closed 16 years ago

web-based handler en-US default options

Categories

(Firefox :: File Handling, defect, P2)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3

People

(Reporter: mic, Assigned: Dolske)

References

(Depends on 1 open bug,
URL
)

Details

Attachments

(1 file)

add Yahoo mail default patch, v1
1.55 KB, patch
Gavin
: review+
beltzner
: approval1.9b4+
Details | Diff | Splinter Review 
We would like to add the following defaults for:

for mailto:
Yahoo Mail
GMail
Windows Live Hotmail

for calendar:
google calendar
yahoo calendar
30 boxes
Flags: blocking-firefox3?
need to get permission from 30 boxes and Msoft - will follow up in bug when this is completed. believe we would have permission from yahoo and google but will double check this as well
How does this work? First time a mailto: link is clicked, if the OS has no mailto: handler, it pops up a dialog saying "Who's your mail provider?" ?

Gerv

it will prompt you to choose one of default choices

here are some good links for more info: 
http://wiki.mozilla.org/ContentHandling:User_Interface
http://wiki.mozilla.org/Firefox3/ContentManagement:Handlers#Protocols

30 boxes approval received from "Narendra Rocherolle" of parent company 83degrees: "That sounds great.". received today. 
Mic: do we want to enable these for beta 3? I'm pretty sure we do, as at least a trial measure.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P2
yes we do. 
I have not been able to reach Microsoft as of yet for permission. So if I can't get them asap (been trying since last week) then I'd have to say enable without Microsoft Live Hotmail. I've pinged Kev and used my contacts for MSoft without luck. I'll ask Lilly if he has a contact we can try.
We already have URL templates that point to live servers ready to accept those templates from the other vendors?
not sure we have them -- double checking with Kev for Google and Yahoo
asked 30 boxes - narender to do this asap
microsoft - now have a contact hope to get that asap too. 

will post back in this bug asap - as I hear back from folks

DMose/Beltzner - can you check milestone to be sure it's set correctly
Target Milestone: Firefox 3 beta3 → Firefox 3
adding dependency to bug 398381 for Yahoo Mail issues (thanks Kev for pointing this out)
Depends on: 398381
Given all the pieces in flux, are we moving this out to B4?
We've been doing this at 30 Boxes for a while and ready to go.  Here's the URL:
http://30boxes.com/external/widget?refer=ff&url=%s

Example:
http://30boxes.com/external/widget?refer=ff&url=http%3A%2F%2Fsports.yahoo.com%2Fnfl%2Fteams%2Fnyj%2Fical.ics

Not sure if this fits in the protocol, but the same url above will do some other cool things:
- the "calendar" url, in addition to the standard ical format, can be any blog page, rss, xml, or just about any structured data with dates, we'll make a calendar out of the dated entries we find in there.
- we'll show multiple calendar data sources on the same calendar, just add more data urls (separated by a space). For example, you could show a sports team's schedule and news feed on the same calendar.

here is Y!Mail
from Manuel Deschamps (thanks Dan)
For Y! Mail we have the following url: http://compose.mail.yahoo.com/?To=%s 
permission from Microsoft (they will fast follow with the right URL):

----- Original Message -----
From: "Aaron Con" <Aaron.Con@microsoft.com>
To: "Michal Berman" <mic@mozilla.com>
Cc: "David Crow" <David.Crow@microsoft.com>, "Dan Mosedale" <dmose@mozilla.com>
Sent: Wednesday, January 30, 2008 1:54:09 PM (GMT-0500) America/New_York
Subject: RE: Hotmail

Hi Michal.

Yes, we'd like to do this. 
from Microsoft, (I'm not sure if it's what we're after):

To make mailto: work, you need to create a URL that follows standard URL encoding and passes us these values:
To = “what goes on the To line”
Cc = “what goes on the CC line”
Subject = “what goes on the subject line”
Body = “what goes in the body of the email”

To create an email to mike@live.com, cc’ing andy@live.com, with the subject “test”, and the body, “test” would look like this:
http://mail.live.com/?rru=compose?to=mike@live.com&subject=test&cc=andy@live.com&body=test

With the proper URL encoding, this becomes:
http://mail.live.com/?rru=compose%3Fto%3Dmike@live.com%26subject%3Dtest%26cc%3Dandy@live.com%26body%3Dtest

Mic: it's not quite what we're looking for.  They have URL that gives us a custom set of parameters.  They'll need to construct a URL that accepts those parameters encoded as an embedded mailto: URL, as specified by the section of the WhatWG link pointed to by <http://whatwg.org/specs/web-apps/current-work/#custom-handlers>.
s/gives us/accepts/
passed on feedback to Microsoft. awaiting update

Nominating for (partial) beta3 blocking.  We should take as many defaults as we think are ready for beta3 so that this feature gets significantly wider test.  This means at least 30 boxes and possibly Yahoo.
Target Milestone: Firefox 3 → Firefox 3 beta3
Priority: P2 → P1
Do we really want to demo a feature with a broken site?

And, would you want to change it in firefox.js only for now, and not add it to region.properties?
Feels like we're rushing this, and I'd rather measure twice, cut once. Moving out to beta 4.
Flags: blocking-firefox3+ → blocking-firefox3-
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
We have permission to go with Google Mail and Calendar, but they currently won't work with the handlers. The latest changes to the Google platform removed this functionality, and while they're working on fixing it, I have no ETA. They have requested we do not incorporate Google links until they've confirmed the fix is in place. I'll ping them again today for an update.
Unless there are contractual obligations binding, i second the decision to move the fix to beta4.  From QA's standpoint, we have to create new testcases for each of these URLs, on a per-locale basis.  We also plan on exporting the default L10n protocol to minotaur, for future tracking of settings.

This test work was estimated by clint to take 3 days. 

(In reply to comment #15)
> Mic: it's not quite what we're looking for.  They have URL that gives us a
> custom set of parameters.  They'll need to construct a URL that accepts those
> parameters encoded as an embedded mailto: URL, as specified by the section of
> the WhatWG link pointed to by
> <http://whatwg.org/specs/web-apps/current-work/#custom-handlers>.

I filed bug 415520 for mailto: Cc/Bcc/Subject/Body support.
Not sure why this is blocking-; since this highlights a P1 feature, I think it's supposed to be blocking+; renominating.  30boxes calendar support has been checked in.

I'll attach a patch for Yahoo mail today.

Mic: any news from the other providers?
Flags: blocking-firefox3- → blocking-firefox3?
From Google:

For gmail mailto you can use:

http://mail.google.com/mail?view=cm&fs=1&tf=1&to={TO}&su={SUBJECT}&body={BODY}&cc={CC}&bcc={BCC}

The to, su, body, cc, and bcc parameters are all optional. The tf=1 parameter is responsible for suppressing the navigation on the right hand side and is also optional.

Kev: that won't work; it has the same issue described in comment 15.  We need Google to provide something that accepts an embedded mailto: URL.
oooh. doh. will read better next time. I'll ping Google and loop you in.
Holding off on the Yahoo patch for now, as either the URL provided here (and in mail from them) is incorrect, or they haven't rolled the necessary bits into production yet.  Mail sent, waiting to hear back...
Not sure this blocks b4, but definitely blocks final ...
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 beta4 → Firefox 3
Priority: P1 → P2
On Tuesday, the Yahoo PM said:

"This has not be pushed out to all users yet.  We are the process of wrapping that up this week.  Assuming no major issues, all free users should have the latest build by the end of the week."

This seems to be working for my account, at least.  Even if they did run into issues and it's not actually working for everyone's account yet (which would result in some people filing bogo-bugs), I think it's worth taking this patch for beta4.  It'll get us significantly more exposure for the web-based protocol handler stuff (the only other default is a webcal: one, and those links are much less common and not used internally like mailto: is).
Attachment #306643 - Flags: review?(gavin.sharp)
Attachment #306643 - Flags: approval1.9b4?
Attachment #306643 - Flags: review?(gavin.sharp) → review+
-> dmose, though there's not really work for him to do here.  I think he owns this for the time being.
Assignee: nobody → dmose
Comment on attachment 306643 [details] [diff] [review]
add Yahoo mail default patch, v1

a1.9b4=beltzner
Attachment #306643 - Flags: approval1.9b4? → approval1.9b4+
Landed this at beltzner's request.
mozilla/browser/locales/en-US/chrome/browser-region/region.properties 	1.24
Flags: in-litmus?
Backed out, as landing this uncovered a latent regression in the injection of default handlers that was caught by one of the unit tests.  Will file a new bug for that.

/cvsroot/mozilla/browser/locales/en-US/chrome/browser-region/region.properties,v  <--  region.properties
new revision: 1.25; previous revision: 1.24
Bug 420756 filed and marked as blocking this one.
Assignee: dmose → dolske
Target Milestone: Firefox 3 → Firefox 3 beta5
Relanded, along with checkin of 420756.

Checking in browser/locales/en-US/chrome/browser-region/region.properties;
  new revision: 1.26; previous revision: 1.25
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I have a problem after this fix.

In the Preferences -> Applications, "Use sylpheed(default)" is displayed as Action
but it doesn't exist in the pull down list.
(sylpheed is a mail client. I use it as default MUA with GNOME)

I build Firefox from CVS trunk.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031822 Firefox 3.0
(Time is JST)

Re-opening, since only the Yahoo default has landed; the others haven't.

Hideo, can you file a new bug about that problem?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 423776
(In reply to comment #38)
 
> Hideo, can you file a new bug about that problem?

I see this, so I filed bug 423776.
(In reply to comment #39)
> (In reply to comment #38)
> 
> > Hideo, can you file a new bug about that problem?
> 
> I see this, so I filed bug 423776.
 
Justin, thank you so much.
Target Milestone: Firefox 3 beta5 → Firefox 3
Hi to all
Any chance to use HTTPS protocol instead of the HTTP for the GMail link?
And for the others if they support it?
That seems like a good idea to me.  In fact, I might even be so bold as to require it, given that the primary motivating use cases for many of these schemes is to allow the entry of personal data.  Earlier in the release cycle such a requirement would definitely have been feasible; I remain hopeful that it still is.
As far as I understand, the implementation on this side of the protocol handler doesn't make any distinction between http vs https, so the question just comes down to the web application that we're targeting.  If they support https then we should use that. If they don't then we'll have to use http.
Blocks: 424704
Kev, 
any update on Google landing their mailto and webcal? Yahoo WebCal and I will get on Hotmail again for their mailto 

AFAICT we only have mailto for yahoo and webcal for 30boxes
We need to set a deadline on new feature requests here, and taking new URLs is really just that.

We should have set it to today, but we didn't. Let's say we're pushing back on it, but we're doing so in days, not in weeks. By next Friday, we will run into trouble getting the changes up in localizations for sure, if not earlier.
heard from MSN Livemail (aka hotmail), the Group Product Manager responsible for our Online Services Mail product. they will not land. 

that leaves us open for another potential choice on mailto. we currently have two, Google and Yahoo, (assuming Google comes through in the next few days). 

---- Original Message -----
From: "Aaron Con" 
To: "Michal Berman" 
Cc: "David Crow" , "Dan Mosedale", "Mike Schackwitz" 
Sent: Friday, March 28, 2008 6:44:21 PM GMT -05:00 US/Canada Eastern
Subject: RE: Hotmail

Hi

Our dev team took a deeper look at your requirements and it turns out that we don't have the code we need, so we won't be able to do this until later this year. It's being added to our specs.  If you have questions, please email our lead Hotmail Program Manager Mike Schackwitz who is cc'd on this mail.

Sorry about that.
Aaron

kev - can you provide an idea of risk wrt Google and Yahoo coming through within next few days i.e., mid to late next week at latest? (we need time for l10n localizers to fast follow once these land) 

if, iyho, risk is high, then we may need a plan b
Depends on: 426107
(In reply to comment #41)

> Any chance to use HTTPS protocol instead of the HTTP for the GMail link?
> And for the others if they support it?

I've spun issue off to bug 426107, rather that overloading this bug further.
Plan B would be a simple mozilla.org-hosted web service which translated the URLs for particular key providers.

So we would do:

gecko.handlerService.schemes.mailto.0.name=Hotmail
gecko.handlerService.schemes.mailto.0.uriTemplate=http://mailhandlers.mozilla.org/hotmail?To=%s

And the "hotmail" servlet/page would send a 301 redirect to the appropriate URL on Hotmail of the form:

http://server.hotmail.com/mailcompose?to=foo&subject=bar&...

Such a servlet would be very simple indeed; but it would need to be written, deployed and tested, which takes time.

Gerv
 


(In reply to comment #49)
> Plan B would be a simple mozilla.org-hosted web service which translated the
> URLs for particular key providers.
That seems to me that we are then supporting providers who aren't following the standard - no?  Couldn't they do the same thing if they really wanted to support this?
Yes, they could, absolutely. But if they will not, for whatever reason, then we have to decide whether we want them in the product enough to do it ourselves, or whether we are happy to ignore them. What would be best for our users?

I think it's pretty likely that there may be at least one email provider that we want to add even if they don't support it themselves; if that is so, it's worth getting the script written and tested, so we can deploy it with the same or new regexps at short notice.

Said email providers may well implement the standard anyway; I doubt they want the user experience of their users being dependent on the uptime of a mozilla.org server.

Gerv

I don't think we should do redirects. We frown upon using redirects through 3rd parties in search for privacy reasons, and I think the same thing applies here. It's not that much a matter of a bad privacy policy, but that the site you're ending up on doesn't link to a privacy policy of the site you sent data to.

Not to mention that Thursday is likely going to be dead-en-US string freeze, and anything had to be said and done and tested by then.
Google will not be ready for our deadline.
(In reply to comment #52)
> Not to mention that Thursday is likely going to be dead-en-US string freeze,
> and anything had to be said and done and tested by then.

As a localizer I don't consider adding protocol handlers to en-US as breaking string freeze. We've got our own handlers in our locale and adding Hotmail, GMail or whatchamacallit to en-US doesn't require any action from us.

The code accepts any number of handlers in region.properties, so if you add a handler to en-US after the freeze, our the tinderboxen will still be green.
(In reply to comment #54)
> (In reply to comment #52)
> > Not to mention that Thursday is likely going to be dead-en-US string freeze,
> > and anything had to be said and done and tested by then.
> 
> As a localizer I don't consider adding protocol handlers to en-US as breaking
> string freeze. We've got our own handlers in our locale and adding Hotmail,
> GMail or whatchamacallit to en-US doesn't require any action from us.

It does for all localizations that use en-US defaults.

> The code accepts any number of handlers in region.properties, so if you add a
> handler to en-US after the freeze, our the tinderboxen will still be green.

... which Mic considers to be a bug. Unfiled, and AFAIK not totally spec'ed down, but that compare-locales is fine with no protocol handlers at all is a bug. Of course fixing that requires en-US defaults, if we don't want to change our comparison logic every other day.
(In reply to comment #53)
> Google will not be ready for our deadline.
> 

Kev, I interpret that as both google mail and google calendar, is that right?
Correct. The components to parse the URIs properly are not in place.
Just wrt comment 54, I just wanted to verify that their "own handlers" don't include Google or other groups discussed who won't make the cutoff. Is that a fair statement?
Whiteboard: [needs status update]
Kev, we'd like to have Google in our locale, but even without it we could ship a localized Firefox with mailto handlers usable for roughly a half of the Polish Internet population. We're waiting for Google and will probably copy en-US handler URL as soon as it's ready, but we're not waiting e.g. for Hotmail.

Fun times.

To clarify:

In order to support protocol handlers, the site in question needs to provide an entry point on their site (preferably https) that takes the complete url as seen by Firefox as an argument in a %s string. Url-encoded, AFAICT.

Now, google won't have that entry point ready by the time we intend to ship, and we're not going to wait on it, neither for mail nor for calendar.

Same goes for hot^H^H^Hlivemail.

Remaining item I see open would be Yahoo Calendar.
Per the Yahoo! mail patch, it just assumes that the first variable passed to it
is the To: address. There is no parsing of the string (i.e. their method
doesn't support the mailto: URI format in RFC2368), it assumes that the first
argument passed in the string will be the To: address, which isn't always
valid.

Try
http://compose.mail.yahoo.com/?To=joe@example.com&cc=bob@example.com&body=hello
and you'll see that all other arguments past joe@example.com are dropped

If this is acceptable to us, then Google's URL meets the same needs. Let me
know.

re: comment #60, it's unclear to me what we're taking as the %s string for the webcal handler. My assumption is that it's a URL pointing to an .ics (iCalendar) file (or ICS formatted file), which would be passed on to the calendar app which would then import the events in that .ics file into the person's calendar. is this correct?
(In reply to comment #61)
> Try
> http://compose.mail.yahoo.com/?To=joe@example.com&cc=bob@example.com&body=hello
> and you'll see that all other arguments past joe@example.com are dropped

Sadly, that's not what we're doing. Instead, we're sending

http://compose.mail.yahoo.com/?To=mailto%3Al10n%40mozilla.com%3Fsubject%3DHi%26body%3Dho

and that yields:

Nothing in new layout for my yahoo account.

If I set it to classic, it tries to send mail to a person called

mailto:l10n@mozilla.com?subject=Hi&body=ho
At this point, should we consider cutting this for FF3 (ie, not ship any default handlers)?

It doesn't sound like we'll have a good set of defaults, and I'm worried by the last few comments that indicate the one(s) we do have don't even work quite right. The risk is that initially shipping with a bad and/or broken set of handlers taints the feature and gives a bad impression of Firefox... It might be better to circle back on this for some later release (FF 3.0.x? FF3.1? FF4?) where we can ensure we ship a good selection of handlers that have been well-tested.

[Of course, if we do this users could still install handlers from sites that support them -- we just wouldn't include them out of the box.]
(In reply to comment #63)
> At this point, should we consider cutting this for FF3 (ie, not ship any
> default handlers)?
> 

What?  How can we get to within a week of RC1 and not have this stuff together?
(In reply to comment #62)
> (In reply to comment #61)
> > Try
> > http://compose.mail.yahoo.com/?To=joe@example.com&cc=bob@example.com&body=hello
> > and you'll see that all other arguments past joe@example.com are dropped
> 
> Sadly, that's not what we're doing. Instead, we're sending
> 
> http://compose.mail.yahoo.com/?To=mailto%3Al10n%40mozilla.com%3Fsubject%3DHi%26body%3Dho
> 
> and that yields:
> 
> Nothing in new layout for my yahoo account.
> 
> If I set it to classic, it tries to send mail to a person called
> 
> mailto:l10n@mozilla.com?subject=Hi&body=ho
> 

Axel is completely correct here.

It seems that every provider we talk to assumes that this concept was designed explicitly for mailto: protocol and, therefore, assume that there server side script is handed just an email address.
schrep: from reading the bug, it looks like two things went wrong. 

Firstly, we didn't start talking to the services about this until near the end of January (comment 0). Secondly, there was a misunderstanding, such that we didn't ask for the right sort of URL/service. That wasn't corrected fully until the end of February (comment 15, comment 27). It looks like we didn't quite realise that this would require work on their side, and initially only asked for permission. And then, clearly some providers (30boxes, comment 11) are more able to make quick changes to their platform than others.

We can have as many handlers as we want if we set up the web service, and deal with any issues Axel raises in the first paragraph of comment #52. I don't think there's a serious privacy issue here. Technically, we could find out who users are sending mail to - but not what they say. They've already installed our binaries on their machine, so they must trust us to quite a degree.

If we do the redirect service, the server-side piece is pretty simple. It takes a mailto URL, url_decodes it, parses it into its component parts (for which there are libraries in every language I know of) then inserts the parts into a new URL and redirects there. 20 lines of Perl (for me), broadly similar in other scripting languages I'm sure.

Gerv

(In reply to comment #66)
> If we do the redirect service, the server-side piece is pretty simple. It takes
> a mailto URL, url_decodes it, parses it into its component parts (for which
> there are libraries in every language I know of) then inserts the parts into a
> new URL and redirects there. 20 lines of Perl (for me), broadly similar in
> other scripting languages I'm sure.

Be careful making a crutch for the providers. Any redirect service has to pass the protocol data the _same_ Firefox does (the entire HREF of the link) and not broken up into parts that are easily consumable by the providers existing infrastructure. Making it easy for them will mean they have no reason to ever do it themselves and we will be running the redirect service for a a long time.
mfinkle: there is that danger, but it could perhaps be mitigated by setting a drop-dead date for when it will go away.
(In reply to comment #66)
> schrep: from reading the bug, it looks like two things went wrong. 
From the QA side of the world, I concur with Gerv.  This definitely got started very late in the game.  We have always had tests for this code in litmus, and they've been run with each release.  The tests for this once used a little bit of cross-site scripting hackery to create a faked handler for the big service providers out there.  We have always only passed in the full mailto: URI to those sites as that is what we are to do per the WHATWG specification.  

We landed a fix that prevented our cross site handler registration which killed the tests that used these third party sites.  So, I created some fake protocol handlers to do testing to be sure that our side of the implementation is working.  We haven't done a ton of testing to vet that all the third party vendors have implemented everything properly, (in fact I've only expected the most minimal of tests to work i.e. mailto:noone@mozilla.org type of URIs) since these bugs are still open which indicates to me that those sites are still in flux.  I made the assumption (which was probably the wrong thing to do) that the folks driving the default registration stuff were making sure this was working as it went by, so I've just kept a cursory eye on this (and the other default handler) bug(s) while working on other things.

I'll follow a follow-on bug for the issues raised in comments 60 and 61 to track the Y! progress with their fix to parse the rest of the mailto: URL. (We can leave this bug open to track the larger question of the complete set of default handlers).
(In reply to comment #61)
> re: comment #60, it's unclear to me what we're taking as the %s string for the
> webcal handler. My assumption is that it's a URL pointing to an .ics
> (iCalendar) file (or ICS formatted file), which would be passed on to the
> calendar app which would then import the events in that .ics file into the
> person's calendar. is this correct?

It is the URL you describe, but the intended semantic is for the calendar app to subscribe to that URL, not simply import the contents there.  The importing use case was intended to be covered by the web-based content-handling functionality, which ultimately got cut.
Depends on: 426260
Opened bug 426260 for tracking the specific Y! issue (it also blocks this bug).
There are a few issues here:

One is documentation, which we're discussing outside of this thread. There is http://developer.mozilla.org/en/docs/Web-based_protocol_handlers, but that's not too prominently linked to anywhere.

Another one is communication, handing out specific timeplans. We've been really reluctant to share timing information about this release (as any other), but sharing a "be done by foo" would have been easily possible here, at least for a quarter.

One is testing, we do have our own testing back end to test our side of the code, but this is obviously a duet to sing.

On testing, who checked 30 boxes? The url we use looks promising, but who checked?

On yahoo testing, their claim that the solution would be partially deployed didn't really help to point out errors from our side, of course, it could still be that that one tester didn't get the feature.

Regarding dismissing the privacy policy and setting up a redirector, mailto URLs are not just To:, but basically include any mail header, including subjects and bodies, as long as they are specified in the URL. So that data would end up in our logs, which isn't really a point where it belongs, IMHO.
URL: http://catb.org/jargon/html/E/error-3... → http://developer.mozilla.org/en/docs/...
No longer depends on: 426260
Depends on: 426260
(In reply to comment #67)
> Be careful making a crutch for the providers. Any redirect service has to pass
> the protocol data the _same_ Firefox does (the entire HREF of the link) and not
> broken up into parts that are easily consumable by the providers existing
> infrastructure. 

I think there's some confusion here. Breaking it up so it's consumable by their existing infrastructure is _exactly_ what I'm suggesting. Why must a redirect service not do this? What would be the point of one which didn't?

> Making it easy for them will mean they have no reason to ever
> do it themselves and we will be running the redirect service for a a long 
> time.

That's a potential risk we have to weigh against what seems like the certainty of not being able to ship the feature. As dmose says, we could set a drop-dead date. Although that risks our shooting ourselves in the foot if it gets near and we have to decide whether to blink. (Our users won't very much like this ability disappearing on them if they are used to it.) 

But from reading comments here, I think that providers are interested in providing the function - and in making it not dependent on the uptime of our servers. Once they've deployed, we can fix the URLs in a point release to take ourselves out of the loop.

One option to make them deploy would be to show interstitial ads for ten seconds before redirecting to the correct URL ;-))

Axel: I agree that mailto: URLs can technically contain subject and body, but when these features are used (which is rarely) the contents are hardly ever sensitive, because they are embedded in web pages! 

Potentially, there might be some risk if it's an intranet. But I still think it's pretty small. People who are worried about this should just not turn the feature on.

Anyway, we can argue this back and forth, but eventually someone's going to have to make a decision. It looks to me like it's redirect service or nothing, at this stage. Microsoft are definitely not deploying in time, and nor are Google (comment #60).

Gerv

(In reply to comment #72)
>
> On testing, who checked 30 boxes? The url we use looks promising, but who
> checked?

I tested it before checking it in.

For webmail users, shipping without any handlers at all is easily the worst user experience: it will start the OS fat mail client which they probably don't use.

The fact that some providers don't handle headers other than the To header doesn't seem like a big deal to me at all: like Gerv, I am under the impression that these usages is pretty rare, and the user experience of getting a mailto page is still better than none.  So having this functionality be useful most of the time seems vastly superior to not at all.

At the very least, I don't see a problem with shipping with the defaults we've got.
Dan, yahoo mail is broken, so we shouldn't ship with it as is.

For webmail users, we'll have the same behaviour as in Firefox 2, unless either they read the docs, or we reverse engineer their site to find out if there's something reasonable to interpolate.
But, unless I'm mistaken, surely the defaults we've got don't work at all? As Pike notes in comment 62, we send e.g.:
http://compose.mail.yahoo.com/?To=mailto%3Al10n%40mozilla.com%3Fsubject%3DHi%26body%3Dho

which will clearly not do the right thing. It might, by chance, do something like the right thing (e.g. start a mail to the literal string email address "mailto:l10n@mozilla.com") but that's still not the right thing.

The way this feature is specced (which, I believe, is a good way) requires explicit server-side support of some kind. This can either me from the provider (30boxes) or from us (redirect service). Those are the options.

Or have I missed something?

Gerv
Yahoo Mail (mostly) works for me.  Despite the fact that their parameters are named in such a way that one would expect it not to work, their code appears to look for the mailto: string in the To: address and strip it out.  So for the common case of links without any other headers, it does Just Work.  The failure mode of dumping other headers into the To field isn't pretty, to be sure, but it still seems notably better than not working at all.
(In reply to comment #78)
> look for the mailto: string in the To: address

That should have read "in the To parameter".
Dan, are you using the new version or classic of yahoo mail? Could you test the other? ;-)

That smells like we're still having a yahoo-deployment issue, if so, do we have an ETA when that deployment is completed?
Blocks: 426371
No longer blocks: 426371
I have fixed the mailto issues in the new Yahoo Mail, I do not know about Classic Mail but I can find out.

links like ?To=mailto:a@example.com?subject=x&body=y   work correctly. (the mailto link must be encoded)


Thank you for the heads up.
dan et al -- 

We need a confirmation that for 3.0.0.0 we will be landing yahoo! for mailto and 30boxes for webcal and they will be working correctly IF NOT this should block Fx3 (RC1) release. 

in conversation with Beltzner this morning we agree that at least one service provider should be there for each of mailto and webcal to demonstrate the feature. 

landing google mail and calendar (and possibly MSN Live Mail) in 3.0.0.1 is acceptable
i have been corrected that I should have written 3.0.1 (vs 3.0.0.1) - my apologies
(In reply to comment #82)

> We need a confirmation that for 3.0.0.0 we will be landing yahoo! for mailto
> and 30boxes for webcal and they will be working correctly IF NOT this should
> block Fx3 (RC1) release. 

Those two handlers have already landed, and are present in Beta 5 (for en-US, at least). There are a few concerns about the completeness / correctness of their implementation (eg bug 426260), but they are actively working on it.
Gerv sees no problem with a redirect service; I strongly believe that's not a road we'd want to go down, since people *will* interpret it as an invasion of privacy, and they can't (easily) verify the redirects aren't logged or that the log data isn't used in some bad way without going out of their way to find a privacy policy.  It also puts server-side burdens on us for something that might be used quite a bit.

However, we do have one option -- ship little HTML files which would do the commandline processing and redirect appropriately, vaguely like so:

<!DOCTYPE html>
<html>
<head>
<title>Redirecting to Gmail...</title>
<!--
Page loaded as so:
chrome://browser/content/gmail-redirector.html?<encoded-URL>
-->
<script type="application/javascript">
(function() {
  var loc = decodeURI(location.search.substring(1));
  var matches = /^mailto:((?:.*?)@(?:.*?))?.*$/.match(loc);
  if (matches)
  {
    location.href = "http://gmail.com/sendMessage?to=" +
                    encodeURIComponent(matches[1]);
    return;
  }

  // misparsed, just redirect
  location.href = "http://gmail.com/";
})();
</script>
</head>
<body>
</body>
</html>

Then we could use these files to do everything client-side, no need for server involvement, and the code that handles it is publicly available for anyone concerned about its quality.

Do we really want to get in the business of verifying the security of these?  I suspect not.  I just wanted to note, however, that our options aren't limited to 1) nothing or 2) full server-side burdens and privacy concerns.
...although, really, there aren't XSS-style security concerns here because a malicious mailto: link might as well have just directly used the malformed Gmail or whatever link.  I don't think it would be hard to ensure the code never used anything XPCOM-y, to prevent privilege escalations.
I'd much rather we work with the providers to convince them to build the support into their applications. If they support it, great, if they don't, we don't put a kludge in place just to make it work with our timelines.
Sorry - should add the rationale as to why I wouldn't want to do client side anything. If, for whatever reason, the service provider makes changes on their application that's not coordinated with the release, we bone the user. 

I'd much prefer to work with the service provider to get it right, and add them post .0 if it's possible.
Random thought, while it's on my mind: In addition to improving docs for handler implementers, it would be useful to have a set of test cases for handler (eg, a page full of mailto: links in various formats). This would help implementers know what to do, and could be used by us as a meter stick to check the compatibility of candidates for shipping in the browser.
Jeff: I think that's a brilliant idea. Any chance of a proof-of-concept patch (or, even better, extension) for e.g. Hotmail or Gmail?

Kev: the providers are unlikely to change their URLs that generate a compose window, because I bet we aren't the only 3rd parties or software using them. Yes, clearly it's better to get them to support the exact format natively but that isn't going to happen for .0 so it's this or nothing. Presumably you are arguing for nothing?

Gerv
Folks, do us all a favour and keep discussions to the actual subject of this bug? The defaults for 3.0 are set, we're damn frozen for good.

If more providers come up, we'll be happy to take them on 3.0.x.

Alternative implementations for implementing protocol handlings are not subject of this bug.
Blocks: 427273
I agree with kev, client side redirects are not a stable option.  What we have now is a good demo of the feature, and I expect that other vendors will want to adopt the whatwg standard, rather than a bunch of random interaction points, especially if it means they're exposed in Firefox.

I don't think there's anything left to block on here.
Flags: blocking-firefox3+ → blocking-firefox3-
Whiteboard: [needs status update]
Depends on: 428905
(In reply to comment #89)
> Random thought, while it's on my mind: In addition to improving docs for
> handler implementers, it would be useful to have a set of test cases for
> handler (eg, a page full of mailto: links in various formats). This would help
> implementers know what to do, and could be used by us as a meter stick to check
> the compatibility of candidates for shipping in the browser.
> 
Guys, I've started this with my page for testing protocol handlers.  This page is referenced from the protocol handler litmus test cases.  I'm happy to take suggestions for more mailto links to add.  If you want something added, open up a bug in the Core Product, Testing component, CC me and add your suggestion.  


(In reply to comment #93)
> Guys, I've started this with my page for testing protocol handlers.  This page
> is referenced from the protocol handler litmus test cases.  I'm happy to take
> suggestions for more mailto links to add.  If you want something added, open up
> a bug in the Core Product, Testing component, CC me and add your suggestion.  
> 
Um... A link would help: http://people.mozilla.org/~ctalbert/test-protocol-links.html

Sorry for the spam.
Blocks: 430258
No longer blocks: 427273
gmail handler has been confirmed as acceptable per testing in comment 94.

The handler URL is:

https://mail.google.com/a/borken.ca/mail/?extsrc=mailto&url=%s

and should be referred to as "Gmail" (may vary in other locales, such as Germany)

The gmail icon should be:
http://mail.google.com/mail/images/favicon.ico

Please let me know if there are any questions regarding Google Gmail as a mailto: handler.
err.. the handler URL is:

http://mail.google.com/mail/?extsrc=mailto&url=%s

thanks to Gavin for pointing out that I specified the hosted apps link. doh.
(In reply to comment #95)
> and should be referred to as "Gmail" (may vary in other locales, such as
> Germany)

Could we get a list of those exceptions?

Note, we don't hardcode the icon, that's somehow grabbed at runtime.

The only one I know about is Germany, where they had to call it "Google Mail" as the result of a trademark infringement there with a company that was already known as "gmail".
This bug is already 100 comments long, and we've only added 1 default so far. I think we should open new bugs for new additions, and mark this one FIXED [or leave it open as a meta bug that will end up lingering around forever :(].
As well as Germany, there's also at least the UK. I suggest you check with Google rather than guessing :-)

Gerv
new bugs opened for mailto for Gmail bug 444395 and Hotmail bug 444399 
so closing this bug :)
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: