Please add Gmail Mailto Protocol Handler to Firefox 3.0.x for en-US. Also please add to 3.0.x for a set of locales tbd (will be added as soon as they are confirmed). gmail protocol has been tested by QA and works the url should be: http://mail.google.com/mail/?extsrc=mailto&url=%s It should be branded "Gmail" in all locales in which it will ship except de where it should be branded "Google Mail"

Since one could access mail.google.com by https, I suggest we change the url to https://mail.google.com/mail/?extsrc=mailto&url=%s ^ for better security.

Mic - I agree with comment 3. Can you clear it with the folks at google?

ok, I'll need help from Kev on that (he has Google contacts). Kev?

dynamis reported the following issue on testing: - "Discard" button will not close mail composition window. I will find a contact at Google to comment

per comment #6, i do not believe this is a block ship issue. I have logged it here to track feature updgrades (if they happen before 3.0.x) on comment 3 - is that a block ship?

(In reply to comment #7) > on comment 3 - is that a block ship? IMHO, yes - I'd much rather give our users a secure connection where their e-mail isn't going to be eavesdropped on (at least to google's servers) instead of sending it in plain text to google.

Gmail now support CC/BCC/Subject/Body (and more?) header parameter but according to RFC 2368 mailer should not interpret BCC header from URL: # See also bug 444399#c16 Note that some headers are inherently unsafe to include in a message generated from a URL. For example, headers such as "From:", "Bcc:", and so on, should never be interpreted from a URL. In general, the fewer headers interpreted from the URL, the less likely it is that a sending agent will create an unsafe message. Same as #6 this will not block ship.

Added test 9 and 10 for the Bcc and From issue. Let me know if you need further changes: http://people.mozilla.org/~ctalbert/test-protocol-links.html

(In reply to comment #4) > Mic - I agree with comment 3. Can you clear it with the folks at google? > I would also like to see fusion.google.com (one of the feed handlers) can be accessed by https and redirect users to iGoogle and Google Reader by https. Currently, iGoogle and Reader can be accessed by https: https://www.google.com/ig https://www.google.com/reader/ but fusion.google cannot: https://fusion.google.com/ Should I create a new bug for this suggestion?

my understanding is the difference between http and https is a significant difference in server load so we should just be aware of this (see original bug for further details). over to kev to be sure we're ok with https vs http (from google's perspective)

Right, using ssl will have more server overhead, but does a better job at protecting a users private data.

(In reply to comment #11) > I would also like to see fusion.google.com (one of the feed handlers) can be > accessed by https and redirect users to iGoogle and Google Reader by https. > Currently, iGoogle and Reader can be accessed by https: > > https://www.google.com/ig > https://www.google.com/reader/ > > but fusion.google cannot: > https://fusion.google.com/ > > Should I create a new bug for this suggestion? > I think this is a google bug and is out of our ability to control. I'd recommend reporting it to google via their bug system.

can i suggest for the purposes of shipping with 3.0.2 that we move to close this bug in the original http url from Google and that if they wish to change it subsequent to release that we do it then. i do this assuming the impact to user experience will be minimal and to expedite their inclusion as many users and locales are looking forward to this feature. from talking with Kevin earlier this week, we have not heard back from Google yet with their permission.

I personally think that it'd be better for our users privacy to wait for a response from Google. A driver should probably chime in though.

I'll touch base with Google today and see what we can get lined up. We'll get resolution one way or another by CoB tomorrow.

Confirmed that the only locales that require "Google Mail" vs. "Gmail" are de and en-GB. All other locales can use "Gmail". HTTPS is approved provided we don't expect a large uptick in use following the upgrade. I would suspect we would not, as most system mailto's are already set to desktop clients. So, using https should be ok, but I'd like feedback on whether we think this would have a dramatic impact against the gmail servers. I don't, but I'm just one person :)

I can't see it being a big uptake. We default to using the system default, which most people have set. You have to go into the applications preference section in order to make it ask in the first place.

Uses https

Comment on attachment 333123 [details] [diff] [review] v2.0 r=me

I can see how this is wanted, but not sure it's blocking. Shawn, is this going to land on trunk soon? It doesn't seem like it'd need much bake time before landing on 1.9.

Once I'm actually around when the tree is green, it'll land. That just seems to be difficult as of late...

We're not going to block on this, but I'll try to find someone to check it in. Would definitely be a nice to have.

Comment on attachment 333123 [details] [diff] [review] v2.0 a=beltzner

Landed on trunk: http://hg.mozilla.org/index.cgi/mozilla-central/rev/c6c66cd62a98

there's actually tests for this!?! This fixes tinderbox orange

Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/7a37832c471a

ecking in uriloader/exthandler/tests/unit/test_handlerService.js; new revision: 1.19; previous revision: 1.18 Checking in browser/locales/en-US/chrome/browser-region/region.properties; new revision: 1.27; previous revision: 1.26

verified fixed on the 1.9.0 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.2pre) Gecko/2008082005 GranParadiso/3.0.2pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.2pre) Gecko/2008082004 GranParadiso/3.0.2pre. verified fixed on the trunk using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080820020636 Minefield/3.1a2pre. One slight issue I noticed is that the "Discard" feature does not work. The way the page is launched, if a user decides to discard the message nothing happens and they are marooned on that page. I can file a new bug on that issue.

They also don't seem to actually support full mailto links with subjects in them. It just dumps everything into the to field :(

What version is this bug? I can still see the bug in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1 (.NET CLR 3.5.30729) But it was working find in version 3.0