Closed
Bug 190120
Opened 22 years ago
Closed 22 years ago
Following mailto links always spawns plain-text Composition windows regardless of "Compose Format" setting
Categories
(MailNews Core :: Composition, defect)
MailNews Core
Composition
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: david, Assigned: ssu0262)
References
Details
(Keywords: regression, Whiteboard: [adt3])
Attachments
(2 files, 4 obsolete files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
ssu0262
:
review+
sspitzer
:
superreview+
asa
:
approval1.4+
|
Details | Diff | Splinter Review |
Clicking on mailto links or using right click->compose to in messenger creates plain text compose windows. Easily duplicated by anybody. My default compose method is HTML.
Comment 1•22 years ago
|
||
Yes, I am having the same symptom. You can see that when you click a mailto: link, the composer window you get has no gui components such as bold, underline etc.
Comment 2•22 years ago
|
||
I am encounting this problem with 1.3B on a Windows 2000 SP2 machine. I did not have the problem with 1.1.
Also reproduced using FizzillaMach/2003021203. Setting All/All. I could've sworn this was a dupe, but I can't find the original report at the moment.
OS: Linux → All
Hardware: PC → All
Summary: Clicking on mailto links or using right click->compose to in messenger creates plain text compose windows → Following mailto links always spawns plain-text Composition windows regardless of "Compose Format" setting
sounds like a dup of bug 167815, but that one was fixed on Jan 30th.
Yes, i saw that. And i have no idea what was fixed in bug 167815 - mailcompose comes up in plaintext mode here too when i click a mailto link in the browser. (current CVS). Perhaps bug 167815 should be reopened.
Comment 8•22 years ago
|
||
My understanding is that plain text is used for security reasons.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Comment 16•22 years ago
|
||
"RESOLVED INVALID" is a not acceptable resolution since this behaviour will block workflows. For example I use a HTML-Page which gives me a full Mail template with references from a database. The current behavior of Mozilla does not create a useful mail template and it can't be used anymore. I will not reopen this bug but I look forward to more comments for this bug and perhaps another one who will reopen it.
Reporter | ||
Comment 18•22 years ago
|
||
Might I ask how it's a security risk? The email address that is opened for composition is already stripped of everything except user@domain.com. A mailto link can't be any more dangerous than any other link, particularly links for javascript. It's highly undesirable to force plain text composition. I use HTML mail for the majority of the data I pass around. Stating that plain text compose is forced because it's a security risk sounds suspiciously like a lame excuse to discourage HTML mail. One can easily 'reply' to HTML mail which can contain every bit as much of a security risk.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 19•22 years ago
|
||
Here here! I strongly disagree with the crippling of mailto capability. I don't know of any other email client behaving this way. If it's an unproven concern, it could be made a preference setting option, "[ ] Disable HTML compose on MailTo"
Comment 20•22 years ago
|
||
in difference to compose a "normal" message (html or/and plain text) the menu "options-format" is also not there in the message window if you click on a mailto link. I say the click on a mailto link should open the mail client in the way it usually opens when someone is creating a new mail. This mailto link is often used to simplify email communication by not typing in the mail address - it would just confuse users if the mail client looks different than they are used to.
Comment 21•22 years ago
|
||
> "it would just confuse users if the mail client looks different than they are used to." It certainly does me! Moreover,its a real pain. Every time I click on a "Contact us" link and want to use italics, or paste in a URL, I have to 1) Swear 2) Open a new compose message window 3) Go to the first message, copy the recipients address, go to the new message and paste it. 4) Go back to the first message, copy the text of my message, go to the new message and paste it. 5) Check the subject I put in the first message and type it into the new message 6) Add the URL or text style I wanted. 7) go back and close the first message before sending the new one. I have to do this all the time. Are we that nuts for thinking this a pain?
Comment 23•22 years ago
|
||
Methinks that the developers consider it too much a hassle to fix. Pity. People will just go back to Netscape 7.
Comment 24•22 years ago
|
||
If security is the primary concern, then maybe the enhancement mentioned in bug 140800 offers the solution: allow a user to change the compose window on the fly between text and HTML. I presume that by first opening the window in text mode, any "offending" text is either removed or shown very explicitly (so it can be edited before the switch), or when switching from text to HTML, tags are treated as text.
Comment 25•22 years ago
|
||
there are a lot of people i contact by clicking mailto links in our university or department directory - aside from making it an incredible pain to send anything in html format, the plain text ruins my html signature file. a minor annoyance that, but i use a plain text sig file when sending plain text. if i'm at my desk running moz mail i want to send in html. i agree with above comments - if it's a security "feature" i at least ought to be able to turn it off.
Comment 27•22 years ago
|
||
This urge to be solved. It appears like a regression to me, since Mozilla 1.2.1 worked right with this. Many sites use "mailto:" by creating a string in javascript that is passed to the command line to pre-format the email. I feel this shouldn't be ignored, since the sender as well as the receiver see a mess in the message. Still, it's more dangerous a plain-text email full of html commands than a well-formed html, since the reader mostly ignores the code as well as the bad layout and he doesn't check the infos he's sending (assuming it's an email generated by filling in a form). This can result in the sending of unclear or hidden informations as well as an html comment. Try to paste this line in the location bar to see the problem: (Mmmh, sorry for my English...)
Comment 28•22 years ago
|
||
mailto:dummy@fakeemail.com?Content-type=text/html&Subject=Try%20this&Body=<html><b>This should be bold</b>, instead <i>this should be in italics</i>.</html>
Comment 29•22 years ago
|
||
Marking nsbeta1 since this is a regression and should work.
Keywords: nsbeta1,
regression
Comment 31•22 years ago
|
||
Still occuring in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030406 Any plan ? Allowing the user to switch back to HTML mode looks to me as a minimum
Flags: blocking1.4b+
Comment 32•22 years ago
|
||
Olivier Vit: unless you are a driver, you do not have authority to set this as blocking 1.4b (+). You can only request it (?) http://www.mozilla.org/roadmap.html#how-you-can-help
Flags: blocking1.4b+
Comment 33•22 years ago
|
||
As stated in Comment #32, I felt it was right to set to "?" the "blocking 1.4b" flag. I've done it since this is a clear regression and it can prevent the accessibility to some sites' services, as said in Comment #18, Comment #19, Comment #25 and Comment #27. Comment #21 shows how it can be frustrating for the standard user. I also confirm it was Ok in Mozilla 1.2.1. Comment #24 propose a possible solution for the problem, although I think it should be asked if it's ok to keep page in html through a popup confirm window.
Flags: blocking1.4b?
Updated•22 years ago
|
Flags: blocking1.4b? → blocking1.4b+
Assignee | ||
Comment 34•22 years ago
|
||
patch fixes this bug, however, it looks like it might regress bug 159786 and/or bug 61893. Still doing more tests...
Comment 35•22 years ago
|
||
that patch doesn't look right. why aren't we getting the default identity, and determining html or txt compose from it? assuming that on pMsgComposeParams, no identity is set. steal from nsMsgComposeService::OpenWindow() [or better yet, make a method to avoid copy and paste] //Use default identity if no identity has been specified nsCOMPtr<nsIMsgIdentity> identity; params->GetIdentity(getter_AddRefs(identity)); if (!identity) { GetDefaultIdentity(getter_AddRefs(identity)); params->SetIdentity(identity); } MSG_ComposeFormat format; params->GetFormat(&format); PRBool composeHTML = PR_TRUE; rv = DetermineComposeHTML(identity, format, &composeHTML); but watch out for this scenario: mozilla suite, mail installed don't set up mail go to browser, click on mailto link (won't have a default identity!) should get mail compose window, and on top, the account wizard. but the compose window is open already so if no default identity, use this pref: mail.html_compose
Assignee | ||
Comment 36•22 years ago
|
||
I think bug 90728 cause this bug. And fixing this bug might regress that bug. Trying to get a better grasp at the problem described in bug 90728.
Status: NEW → ASSIGNED
Comment 37•22 years ago
|
||
The fix for bug 90728 did two things that I consider orthogonal: 1. Made mailto: links default to text/plain, removed the force-plain-text parameter, and added an html-body parameter. (Since this only changes the default without removing the possibility of including HTML, it has no effect on security, and I don't know why it was done.) 2. Made HTML bodies supplied by mailto: URLs go through the HTML sanitizer. (I'm not familiar with the HTML sanitizer, so I don't know whether this fixes the hidden-text or the hidden-script versions of the security hole. And the fix for bug 159786 might have re-introduced the hole.)
Assignee | ||
Comment 38•22 years ago
|
||
Updated patch that fixes this bug and still sanitizes html bodies in the url, as far as I can tell. My test cases showes that the sanitize code is still being done. mailto: links will now default the current/default mail account's 'Compose messages in HTML format' pref located in the "Mail & Newsgroups Account Settings...". You can only override it to HTML mail composer (not to PlainText) by having either the 'html-part' or 'html-body' tag in the url, eg: mailto:user@domain.com:html-body=This will force the mail compose window to come up in HTML edit mode. Test case coming up.
Attachment #122267 -
Attachment is obsolete: true
Assignee | ||
Comment 39•22 years ago
|
||
Assignee | ||
Comment 40•22 years ago
|
||
typo. instead of: mailto:user@domain.com:html-body=This... It should be: mailto:user@domain.com?html-body=This... ^ The attached test case is correct though.
Attachment #122363 -
Flags: superreview?(sspitzer)
Attachment #122363 -
Flags: review?(jruderman)
Comment 41•22 years ago
|
||
Comment on attachment 122363 [details] [diff] [review] patch v1.1 1) + nsresult GetIdentityAndFormat(nsIMsgComposeParams *aParams, PRBool *aComposeHtml); you need to remove that. 2) +#include "nsIMsgComposeParams.h" is this necessary, since you added +#include "nsIMsgComposeParams.idl" to public/nsISmtpUrl.idl
Attachment #122363 -
Flags: superreview?(sspitzer) → superreview-
Attachment #122363 -
Attachment is obsolete: true
Attachment #122363 -
Flags: review?(jruderman)
Assignee | ||
Comment 42•22 years ago
|
||
updated patch that addresses sspitzer's comments. both lines removed.
Attachment #122377 -
Flags: superreview?(sspitzer)
Attachment #122377 -
Flags: review?(jruderman)
Comment 43•22 years ago
|
||
To keep the patch nearer to standards, could we use a different syntax to override the compose settings (see Comment #38)? I purpose the use of "Content-type=text/html" at the command line. Example given: mailto:user@domain.com?Content-type=text/html instead of: mailto:user@domain.com?html-body=This This will be more clearer and won't be just a Mozilla pref, but exportable to other browsers too. I'm not sure, but maybe also Outlook use this syntax... Thank you for the attention, just my 2 cents anyway...
Comment 44•22 years ago
|
||
In current versions of Mozilla, the value of html-body is ignored; the presence of html-body just means that the value of body should be treated as HTML. The patch changes html-body so its value matters and overrides the body value. I like this change, because it allows better compatibility with clients that do not support or do not default to HTML message compose. I disagree with #1 and #3 in the testcase. I think a mailto: link with a body= parameter should do the same thing regardless of the user's pref. Web site authors who put up mailto: links with body= values are unlikely to think of the problem of user's prefs interfering with how the body= value is interpreted. But I agree with #5 in the testcase. A mailto: link without a body= (the most common case) should bring up a message-compose window set to HTML or plain-text depending on the user's pref. How about this: * mailto: links with html-body= always bring up HTML message compose, and any body= value is ignored. * mailto: links with only body= always bring up plain-text message compose (to match Outlook Express 6.00.2800.1123 and to make Mozilla Mail more predictable). * mailto: links with neither go with the user's pref.
Comment 45•22 years ago
|
||
In last comment you said: * mailto: links with only body= always bring up plain-text message compose I dunno if it's the better thing to do, however the user should be able to set a preference about it. Still, it should be possible to switch to HTML mode whenever wanted. Personally, I prefer the behaviour of the 1.2.1 Mozilla release, where the "body" was in html unless otherwise specificated (in prefs or switching manually to plain text). This is useful for sites which use javascript to send a form through a link, after having assembled it in a formatted email, or either created complex user-editable tables. Many times a particular formatting is necessary because the receiver uses a mail filter to label incoming messages. If you think that this could violate any security issue, please consider that a malicious site could always use php to send away private informations, and in a more subtle and dangerous manner (also the IP number). And no report of the operation would be given to the end user. So, trustworthy users will be penalized, and malicious ones could always switch to php or something similar. When I used some services inside an italian site with these preformatted emails, and I asked for an alternative manner to send them my informations, they said just "revert to Microsoft Outlook, that will work better". Sad, isn't it? So I had to cut and copy about 25-30 emails in new messages, reformat them properly (subject and address) and send them. I know it isn't the best way to project a site, but a lot of people use the mailto: pseudo-protocol in this way.
Comment 46•22 years ago
|
||
Are people already depending on html-body? If not, I like Matteo's suggestion of using Content-Type instead. Even if it is in use, we might want to deprecate it and go with Content-Type instead, since that method is compliant with RFC 2368. Modulo that, I think I agree with Jesse's proposal in comment 44. In particular mailto:mailing-list-request@foo.com?body=subscribe is a commonly used link, and I would think that most list processors will barf on that if it's surrounded by html junk. Matteo: I'm having a hard time understanding your comment 45. Are you saying that Outlook behaves differently than Jesse describes Outlook Express as behaving?
Comment 47•22 years ago
|
||
Sean and I just did some testing, and, interestingly, Outlook seems to default to choosing HTML compose with body=, but send multipart/alternative: one part text/html and one part plain. So newer list processors that grok MIME (are there such things? are they common?) might do OK with that.
Comment 48•22 years ago
|
||
Uh, sorry for my English. However, Outlook Express 5 and others behave treating new messages as multipart (see above comment). My last comment focused on the security problem, for this seems to be the most important thing to consider when setting new messages to compose in html. The security issue that was discussed is: "could some private informations be sent through a html comment hidden to the user in html composed messages?" My point was that html messages through "mailto" are useful to many companies, and not supporting it would prevent some user to access some sites' services, also because these companies could use automatic scripts (or email filters) to catalogue incoming messages. It is true that also plain text messages would work with most of these filters, but the resulting email would be pretty complicated to read. The example I reported in my previous comment was that of an italian site that asked me to change email client because otherwise they would ignore my emails. Let's do an example: <form action="user@domain.com" name="we"> <input type="hidden" name="type" value="text/html"> <input type="text" name="subject"> <input type="text" name="body"> <input type="text" name="nickname"> <input type="password" name="privateinfo"> <input type="button" value="Send it!" onClick="writeEmail(document.we.type.value, document.we.subject.value, document.we.body.value, document.we.privateinfo.value, document.we.nickname.value);"> </form> Note that just : "text/plain" and "text/html" should be supported (and also "multipart/alternative" if you want), but not any other type as "octet/stream"! Here's the js code that build up the email body (hope there's no error, I'm writing it "on the fly") <script language="JavaScript" type="text/javascript"> <!-- function writeEmail($type, $title, $body, $privateinfo, $name) { var validate = true; if ($title == '' || $body == '' || $name == '') {validate = false}; if (validate) { $today = new Date(); $todaydate = $today.toUTCString(); re = new Array(); rewith = new Array(); re = [ /%/gi, /&/gi, /\n/gi, /Γ¨/gi, /Γ©/gi, /Γ²/gi, /Γ /gi, /ΓΉ/gi, /Γ¬/gi, /Β£/gi, /Γ§/gi, /Β°/gi, /Β§/gi, // /</gi, // />/gi, ]; rewith = [ "%25", "%26", "\<br\>", "e'", "e'", "o'", "a'", "u'", "i'", "pnd", "c", "<sup>o</sup>", "<b>sign</b>", // "%3C", // "%3E", ]; for (h = 0; h < 15; ++h) { $body = $body.replace(re[h], rewith[h]); } $send = ('mailto:user@domain.com?'); $send += ('Content-type=' + $type + '&'); $send += ('Subject=[' + $title + ']' + &MIME-Version=1.0&charset=iso-8859-1&'); $send += ('Body=\<html\>\<body\><p style=\"color : #000066\"> On ' + $todaydate + ', '); $send += ($name + ' wrote : \n\<\/p\>\<ul style=\"border-left : black 1px solid; padding-left : 5px\"\>"' + $body + '"\<\/ul\>\<p style=\"color : #000066\"\>Sent by : www.domain.com\<\/p\>'); //watch out the following line ... $send += '<!-- Private info: ' + $privateinfo + '-->'; $send += ('\<\/body\>\<\/html\>'); self.location.href = $send; } else { alert('\tError'); } } // --> </script> This is just a poor example. Think about a form where you insert some values and the resulting email includes a table that has already sums calculated and also a graph (with the use of DIVs and CSS, it can be done). You can just send one email per time with js, and the recipient is shown in clear. So, what's the security problem? Any information has been inserted awarely by the user, and it is intended to be sent. Confirmation is ALWAYS asked before the sending. On the other hand, malicious companies have not interest in using the "mailto" pseudo-protocol to send away messages with hidden informations, since they can compose mail through the "mail()" PHP function, just to give an example. And this could contain more private infos that those sent with javascript, as the IP number. More, user won't have any feedback. So, there's no reason to block html composing, since good companies will have to change their Hope it's clearer, sorry for the english. Thank you for your patience.
Comment 49•22 years ago
|
||
There were a few mistakes in the code above. Created a testcase at http://www.intelligenzartificiale.it/html/spe_contact.htm Description is in italian, but you won't have any problem at filling it and testing. If anyone of you has a previous release of Mozilla (such as 1.2.1), the old behaviour is shown. In this example, Outlook will attach a file at the email (because of the form's method). This file can be saved, renamed to .htm and viewed.
Reporter | ||
Comment 50•22 years ago
|
||
I write a list processor that will handle html in depth in a little while, it handles simple html now.
Assignee | ||
Comment 51•22 years ago
|
||
We're running out of time. I'm going to fix the problem initially stated in this bug. People who want other/enhanced mailto: url support should open new bug on it.
Assignee | ||
Comment 52•22 years ago
|
||
update patch given review with dmose.
Attachment #122377 -
Attachment is obsolete: true
Assignee | ||
Comment 53•22 years ago
|
||
forgot one minor change.
Attachment #122551 -
Attachment is obsolete: true
Attachment #122377 -
Flags: superreview?(sspitzer)
Attachment #122377 -
Flags: review?(jruderman)
Comment 54•22 years ago
|
||
r=dmose@mozilla.org for patch v1.4. This doesn't address the Content-Type issue or Jessie's and my semantic issues, but I think it does make things perform as expected more of the time than they do in currect builds. Please file a new bug on the remaining issues from this bug, including one about popping up an error message if the HTML sanitizing parser fails rather then just dumping HTML gunk into the plaintext compose window.
Assignee | ||
Comment 55•22 years ago
|
||
Comment on attachment 122552 [details] [diff] [review] patch v1.4 got r=dmose seeking sr= and a=
Attachment #122552 -
Flags: superreview?(sspitzer)
Attachment #122552 -
Flags: review+
Attachment #122552 -
Flags: approval1.4b?
Comment 56•22 years ago
|
||
Comment on attachment 122552 [details] [diff] [review] patch v1.4 sr/a=sspitzer another spin off bug (low priority) use the "right" identity when the mailto link is in an email message. also, just double checking, do we use the "right" identity when you click on an address in the msg hdr pane?
Attachment #122552 -
Flags: superreview?(sspitzer)
Attachment #122552 -
Flags: superreview+
Attachment #122552 -
Flags: approval1.4b?
Attachment #122552 -
Flags: approval1.4b+
Updated•22 years ago
|
Flags: blocking1.4b-
Flags: blocking1.4b+
Flags: blocking1.4+
Updated•22 years ago
|
Attachment #122552 -
Flags: approval1.4b+ → approval1.4+
Comment 57•22 years ago
|
||
Can we have the patch improved for 1.4 final? It would be interesting to have the Content-type request fixed, if possible (See Comment #46).
Assignee | ||
Comment 58•22 years ago
|
||
> another spin off bug (low priority) use the "right" identity when the mailto > link is in an email message. opened bug 204911. > also, just double checking, do we use the "right" identity when you click > on an address in the msg hdr pane? This works great. > To keep the patch nearer to standards, could we use a different syntax to > override the compose settings (see Comment #38)? > I purpose the use of "Content-type=text/html" at the command line. opened bug 204914. patch v1.4 checked in. closing this bug as fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 59•22 years ago
|
||
OK, so this is marked fixed. Yet my spiffy new 1.4b still pops up with a mail window that does not allow me to insert a url or mark something in italics. See comment #21. I still withhold recommendation of Mozilla as a suitable client. I use it, but this is such an irritating flaw that I won't stake my recommendations on it.
Assignee | ||
Comment 60•22 years ago
|
||
that *just* got checked in, so obviously it won't be in 1.4b cause it's already released. This fix should show up in 1.4f though.
Comment 63•22 years ago
|
||
Using trunk build 20030519 on winxp, macosx and linux and the original scenario this bug is fixed. Clicking on a mailto link within a browser page will bring up a compose window in the format selected for the default mail account in either HTML or plain text.
Status: RESOLVED → VERIFIED
Comment 65•22 years ago
|
||
on comment #58 >> also, just double checking, do we use the "right" identity when you click >> on an address in the msg hdr pane? >This works great. This is not working in 1.4RC2 When I click on a mailto: link in MailNews in a seconday account, the "right" identity is not used. Instead, the default Identity is used. Bug #194809 is still open regarding this issue. It is late for including a patch for 1.4rc3? Thanks
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•