Closed
Bug 413630
Opened 17 years ago
Closed 17 years ago
web-based handler en-US default options
Categories
(Firefox :: File Handling, defect, P2)
Firefox
File Handling
Tracking
()
RESOLVED
FIXED
Firefox 3
People
(Reporter: mic, Assigned: Dolske)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file)
(deleted),
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?
Reporter | ||
Comment 1•17 years ago
|
||
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
Comment 2•17 years ago
|
||
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
Reporter | ||
Comment 3•17 years ago
|
||
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
Reporter | ||
Comment 4•17 years ago
|
||
30 boxes approval received from "Narendra Rocherolle" of parent company 83degrees: "That sounds great.". received today.
Comment 5•17 years ago
|
||
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
Reporter | ||
Comment 6•17 years ago
|
||
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.
Comment 7•17 years ago
|
||
We already have URL templates that point to live servers ready to accept those templates from the other vendors?
Reporter | ||
Comment 8•17 years ago
|
||
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
Reporter | ||
Comment 9•17 years ago
|
||
adding dependency to bug 398381 for Yahoo Mail issues (thanks Kev for pointing this out)
Depends on: 398381
Comment 10•17 years ago
|
||
Given all the pieces in flux, are we moving this out to B4?
Comment 11•17 years ago
|
||
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.
Reporter | ||
Comment 12•17 years ago
|
||
here is Y!Mail
from Manuel Deschamps (thanks Dan)
For Y! Mail we have the following url: http://compose.mail.yahoo.com/?To=%s
Reporter | ||
Comment 13•17 years ago
|
||
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.
Reporter | ||
Comment 14•17 years ago
|
||
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
Comment 15•17 years ago
|
||
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>.
Comment 16•17 years ago
|
||
s/gives us/accepts/
Reporter | ||
Comment 17•17 years ago
|
||
passed on feedback to Microsoft. awaiting update
Comment 18•17 years ago
|
||
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
Updated•17 years ago
|
Priority: P2 → P1
Comment 19•17 years ago
|
||
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?
Comment 20•17 years ago
|
||
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
Comment 21•17 years ago
|
||
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.
Comment 22•17 years ago
|
||
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.
Comment 23•17 years ago
|
||
(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.
Comment 24•17 years ago
|
||
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?
Comment 25•17 years ago
|
||
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.
Comment 26•17 years ago
|
||
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.
Comment 27•17 years ago
|
||
oooh. doh. will read better next time. I'll ping Google and loop you in.
Comment 28•17 years ago
|
||
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...
Comment 29•17 years ago
|
||
Not sure this blocks b4, but definitely blocks final ...
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 beta4 → Firefox 3
Updated•17 years ago
|
Priority: P1 → P2
Comment 30•17 years ago
|
||
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?
Updated•17 years ago
|
Attachment #306643 -
Flags: review?(gavin.sharp) → review+
Comment 31•17 years ago
|
||
-> 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 32•17 years ago
|
||
Comment on attachment 306643 [details] [diff] [review]
add Yahoo mail default patch, v1
a1.9b4=beltzner
Attachment #306643 -
Flags: approval1.9b4? → approval1.9b4+
Comment 33•17 years ago
|
||
Landed this at beltzner's request.
mozilla/browser/locales/en-US/chrome/browser-region/region.properties 1.24
Updated•17 years ago
|
Flags: in-litmus?
Comment 34•17 years ago
|
||
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
Comment 35•17 years ago
|
||
Bug 420756 filed and marked as blocking this one.
Assignee | ||
Updated•17 years ago
|
Assignee: dmose → dolske
Assignee | ||
Updated•17 years ago
|
Target Milestone: Firefox 3 → Firefox 3 beta5
Assignee | ||
Comment 36•17 years ago
|
||
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: 17 years ago
Resolution: --- → FIXED
Comment 37•17 years ago
|
||
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)
Comment 38•17 years ago
|
||
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 → ---
Assignee | ||
Comment 39•17 years ago
|
||
(In reply to comment #38)
> Hideo, can you file a new bug about that problem?
I see this, so I filed bug 423776.
Comment 40•17 years ago
|
||
(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.
Updated•17 years ago
|
Target Milestone: Firefox 3 beta5 → Firefox 3
Comment 41•17 years ago
|
||
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?
Comment 42•17 years ago
|
||
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.
Comment 43•17 years ago
|
||
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.
Reporter | ||
Comment 44•17 years ago
|
||
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
Comment 45•17 years ago
|
||
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.
Reporter | ||
Comment 46•17 years ago
|
||
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
Reporter | ||
Comment 47•17 years ago
|
||
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
Assignee | ||
Comment 48•17 years ago
|
||
(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.
Comment 49•17 years ago
|
||
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
Comment 50•17 years ago
|
||
(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?
Comment 51•17 years ago
|
||
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
Comment 52•17 years ago
|
||
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.
Comment 53•17 years ago
|
||
Google will not be ready for our deadline.
Comment 54•17 years ago
|
||
(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.
Comment 55•17 years ago
|
||
(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.
Comment 56•17 years ago
|
||
(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?
Comment 57•17 years ago
|
||
Correct. The components to parse the URIs properly are not in place.
Comment 58•17 years ago
|
||
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?
Updated•17 years ago
|
Whiteboard: [needs status update]
Comment 59•17 years ago
|
||
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.
Comment 60•17 years ago
|
||
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.
Comment 61•17 years ago
|
||
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?
Comment 62•17 years ago
|
||
(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
Assignee | ||
Comment 63•17 years ago
|
||
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.]
Comment 64•17 years ago
|
||
(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?
Updated•17 years ago
|
Comment 65•17 years ago
|
||
(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.
Comment 66•17 years ago
|
||
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
Comment 67•17 years ago
|
||
(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.
Comment 68•17 years ago
|
||
mfinkle: there is that danger, but it could perhaps be mitigated by setting a drop-dead date for when it will go away.
Comment 69•17 years ago
|
||
(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).
Comment 70•17 years ago
|
||
(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.
Comment 71•17 years ago
|
||
Opened bug 426260 for tracking the specific Y! issue (it also blocks this bug).
Comment 72•17 years ago
|
||
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.
No longer depends on: 426260
Comment 73•17 years ago
|
||
(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
Comment 74•17 years ago
|
||
(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.
Comment 75•17 years ago
|
||
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.
Comment 76•17 years ago
|
||
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.
Comment 77•17 years ago
|
||
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
Comment 78•17 years ago
|
||
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.
Comment 79•17 years ago
|
||
(In reply to comment #78)
> look for the mailto: string in the To: address
That should have read "in the To parameter".
Comment 80•17 years ago
|
||
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?
Comment 81•17 years ago
|
||
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.
Reporter | ||
Comment 82•17 years ago
|
||
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
Reporter | ||
Comment 83•17 years ago
|
||
i have been corrected that I should have written 3.0.1 (vs 3.0.0.1) - my apologies
Assignee | ||
Comment 84•17 years ago
|
||
(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.
Comment 85•17 years ago
|
||
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.
Comment 86•17 years ago
|
||
...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.
Comment 87•17 years ago
|
||
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.
Comment 88•17 years ago
|
||
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.
Assignee | ||
Comment 89•17 years ago
|
||
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.
Comment 90•17 years ago
|
||
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
Comment 91•17 years ago
|
||
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.
Comment 92•17 years ago
|
||
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-
Assignee | ||
Updated•17 years ago
|
Whiteboard: [needs status update]
Comment 93•17 years ago
|
||
(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.
Comment 94•17 years ago
|
||
(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.
Updated•17 years ago
|
Comment 95•17 years ago
|
||
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.
Comment 96•17 years ago
|
||
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.
Comment 97•17 years ago
|
||
(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.
Comment 98•17 years ago
|
||
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".
Assignee | ||
Comment 99•17 years ago
|
||
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 :(].
Comment 100•17 years ago
|
||
As well as Germany, there's also at least the UK. I suggest you check with Google rather than guessing :-)
Gerv
Reporter | ||
Comment 101•17 years ago
|
||
new bugs opened for mailto for Gmail bug 444395 and Hotmail bug 444399
so closing this bug :)
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•