Closed
Bug 444395
Opened 17 years ago
Closed 16 years ago
Add Gmail Mailto protocol handler to Firefox 3.0.x
Categories
(Firefox :: File Handling, defect)
Tracking
()
VERIFIED
FIXED
Firefox 3.1a2
People
(Reporter: mic, Assigned: sdwilsh)
References
Details
(Keywords: verified1.9.0.2)
Attachments
(2 files, 1 obsolete file)
1.45 KB,
patch
|
mconnor
:
review+
beltzner
:
approval1.9.0.2+
|
Details | Diff | Splinter Review |
2.59 KB,
patch
|
Details | Diff | Splinter Review |
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"
Assignee | ||
Comment 2•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Whiteboard: [has patch][needs review gavin]
Target Milestone: --- → Firefox 3.1a1
Comment 3•17 years ago
|
||
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.
Assignee | ||
Comment 4•17 years ago
|
||
Mic - I agree with comment 3. Can you clear it with the folks at google?
Reporter | ||
Comment 5•17 years ago
|
||
ok, I'll need help from Kev on that (he has Google contacts). Kev?
Reporter | ||
Comment 6•17 years ago
|
||
dynamis reported the following issue on testing: - "Discard" button will not close mail composition window.
I will find a contact at Google to comment
Reporter | ||
Comment 7•17 years ago
|
||
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?
Assignee | ||
Comment 8•17 years ago
|
||
(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.
Comment 9•17 years ago
|
||
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.
Comment 10•17 years ago
|
||
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
Comment 11•17 years ago
|
||
(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?
Reporter | ||
Comment 12•16 years ago
|
||
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)
Assignee | ||
Comment 13•16 years ago
|
||
Right, using ssl will have more server overhead, but does a better job at protecting a users private data.
Comment 14•16 years ago
|
||
(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.
Reporter | ||
Comment 15•16 years ago
|
||
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.
Assignee | ||
Comment 16•16 years ago
|
||
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.
Comment 17•16 years ago
|
||
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.
Comment 18•16 years ago
|
||
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 :)
Assignee | ||
Comment 19•16 years ago
|
||
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.
Whiteboard: [has patch][needs review gavin] → [needs new patch]
Assignee | ||
Updated•16 years ago
|
Attachment #328729 -
Attachment is obsolete: true
Attachment #328729 -
Flags: review?(gavin.sharp)
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.0.2?
Flags: blocking-firefox3.1?
Whiteboard: [needs new patch] → [has patch][needs review gavin]
Target Milestone: Firefox 3.1a1 → Firefox 3.1a2
Comment 21•16 years ago
|
||
Comment on attachment 333123 [details] [diff] [review]
v2.0
r=me
Attachment #333123 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•16 years ago
|
Whiteboard: [has patch][needs review gavin] → [has patch][has review][can land]
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Comment 22•16 years ago
|
||
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.
Flags: wanted1.9.0.x+
Assignee | ||
Comment 23•16 years ago
|
||
Once I'm actually around when the tree is green, it'll land. That just seems to be difficult as of late...
Comment 24•16 years ago
|
||
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.
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.2-
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Comment 25•16 years ago
|
||
Comment on attachment 333123 [details] [diff] [review]
v2.0
a=beltzner
Attachment #333123 -
Flags: approval1.9.0.2+
Comment 26•16 years ago
|
||
Landed on trunk: http://hg.mozilla.org/index.cgi/mozilla-central/rev/c6c66cd62a98
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 27•16 years ago
|
||
there's actually tests for this!?! This fixes tinderbox orange
Assignee | ||
Comment 28•16 years ago
|
||
Pushed to mozilla-central:
http://hg.mozilla.org/mozilla-central/index.cgi/rev/7a37832c471a
Whiteboard: [has patch][has review][can land]
Assignee | ||
Comment 29•16 years ago
|
||
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
Keywords: checkin-needed → fixed1.9.0.2
Comment 30•16 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.2 → verified1.9.0.2
Assignee | ||
Comment 31•16 years ago
|
||
They also don't seem to actually support full mailto links with subjects in them. It just dumps everything into the to field :(
Comment 32•16 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•