Closed Bug 21322 Opened 25 years ago Closed 22 years ago

Mailto URL handler drops CRLF in body= parameter

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: phil, Assigned: mscott)

References

Details

(Whiteboard: [nsbeta3-])

Attachments

(1 file)

Adds Switch/Case which fixes bug in mailto: situation
937 bytes, patch
Details | Diff | Splinter Review 
Subject: mailto:
        Date: Thu, 09 Dec 1999 16:55:12 -0500
        From: "Brian J. White" <brian@centralad.com>
Organization: Central Ad Software, Inc.
  Newsgroups: netscape.public.mozilla.wishlist

As I was concerned, the mailto: functionality doesn't appear to work
just yet.  Try creating a page with the following HTML tag in it:

<a
href="mailto:you@netscape.net?subject=subject&body=line1%0D%0Aline2%0D%0A">CLICK
ME</a>

When clicking on the link, the body should be:

line1
line2

Instead, it is rendered:

line1 line2

My GUESS is that the message compose window is treating the %0D%0A as an
HTML return (basically, as a SPACE) as opposed to a <br>

I am using yesterday's Mozilla build in the testing.

Brian
Target Milestone: M16
Will this be taken care of before the final release?   I'm concerned because I
rely heavily on the standard functionality of MAILTO: links in my day-to-day
operations.  Many of my outgoing emails are dynamically generated by my server
and presented as MAILTO links -- subject, body and all.  This way, I can save a
copy of the email in my SENT folder (as opposed to the server sending it
directly).   Anyway, it's very important that I be able to include a CRLF in the
body of these emails.

Yup, this will be fixed before we ship...just not before beta 1.


Awesome.  You guys rock.  :)
Not M16 stopper.  Marking M17.
Target Milestone: M16 → M17
nominating for beta3 and moving to M18
Keywords: nsbeta3
Target Milestone: M17 → M18
Keywords: mail2
- per mail triage
Whiteboard: [nsbeta3-]
Keywords: mail2 → mail6
Sorry for the extra email. Removing mail6 keyword.
Keywords: mail6
The attached .diff file is my first contribution to Mozilla -- that's why I
didn't simply use CVS check in.

I have tested the latest source (Oct 30, 2000) with and without this proposed
change and found that this fix does address this bug.   I have found no reason
to believe the proposed fix affects/creates any other bugs or functionality.

Thanks.
Why is it necessary to set m_composeHTML to false? I understand that the
contents of the mailto URL are defined to be text/plain, but aren't you
overriding the user's HTML composition preference?
When I wrote it that way, I had the same thought.  However, the composition
window is STILL presented in HTML format and the message IS formatted properly.

The way I tested was to click on a length mailto: link after setting the account
preferences to text-compose and then to html-compose.  The result was that when
in text-compose mode, the mailto link created a composition window that was
formatted properly and in a fixed-width font [just like pre-patch.]   When I set
my account settings to HTML-compose, a click on the mailto link generated a
composition window that was formatted properly [unlike BEFORE the patch] and was
in variable width font.


Works on 0.7, looks like this one slipped through...

Should probably be marked as fixed, but I'd just like to make sure that this
works on all platforms before doing so...
I just downloaded the latest build (2001020804) to test this bug.  This build
does NOT fix this bug.  A test URL is:

http://wavcentral.com/mozilla/mailto.html

If you set the Mail Account Settings to "Compose messages in HTML", the above
page will generate an email formated like:

line1 line2

If you then change the account settings to composing in plain/text, the link
will generate properly:

line1
line2

The previous attachment I made to this bug report will retire this bug, however
it has not been applied to the source tree (I just double-checked the current
source tree).  I apologize if my submission methods/procedures were incorrent,
however this was my only src contribution [It's very important to me that this
work].

Thanks
similar but to 69638?  not sure this is a dup.

I don't think it's a duplicate of this bug, but it may be related
Target Milestone: M18 → ---
Severity: minor → normal
Keywords: nsbeta3 → mozilla1.0
Ducarroz, maybe you can (finally) get this reviewed and checked it?  Thanks.
This patch is not good because you cannot set m_composeHTML to false just like that. If the compose window is by 
default in HTML mode, we need to correlty convert the body received instead to kind of turning off HTML mode! 

I would rather see a patch directly in the function ConvertAndLoadComposeWindow.

can you try this instead (sorry for th bad quality of the patch but I have tone
of other moduf in this file in my tree:

in function ConvertAndLoadComposeWindow in file nsMsgCompose.cpp

   else
   {
     if (aHTMLEditor)
     {
       if (!aBuf.IsEmpty())
-        aEditorShell->InsertSource(aBuf.GetUnicode());
+      {
+         /* In case of a mailto, the buffer is always plain text */
+        if (mType == nsIMsgCompType::MailToUrl) 
+          aEditorShell->InsertText(aBuf.GetUnicode());
+        else
+          aEditorShell->InsertSource(aBuf.GetUnicode());
+      }
       if (!aSignature.IsEmpty())
         aEditorShell->InsertSource(aSignature.GetUnicode());
     }
     else
     {
       if (!aBuf.IsEmpty())

In build 2001112603, this appears to still be broken;  CR/LF
is getting completely dropped (not converted to a space).
This happens whether or not I have "Compose messages in HTML format"
checked.
just wondering if there is any progress with this?  This feature is part of
being compliant with rfc2368 -
http://www.cis.ohio-state.edu/cs/Services/rfc/rfc-text/rfc2368.txt
Just thought I'd add a comment that this bug still exists with Mozilla RC1
running on OS/2 (actually eComStation Pro 1.01).  
mozilla 1.1a and the bug is still there.
we plan to include errordata in the mailto links of
our errorpages so we really need this to be fixed.

*** Bug 165871 has been marked as a duplicate of this bug. ***
*** Bug 143436 has been marked as a duplicate of this bug. ***
*** Bug 147719 has been marked as a duplicate of this bug. ***
I just tried the example given (<a
href="mailto:you@netscape.net?subject=subject&body=line1%0D%0Aline2%0D%0A">CLICK
ME</a>) and it works with the latest trunk build (2002121108 WinXP) but it does
not work on the new NS7.01.
Removing mozilla1.0 as that is long, long past.

Based on comment 26, I am also marking this bug as fixed.

-M
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0
Resolution: --- → FIXED
This issue again exists in Mozilla 1.5 RC2. Mozilla 1.4 worked fine. As this is
a very old bug on a feature used on many sites I ask to block 1.5 although I
cannot provide a patch.
Flags: blocking1.5+
Olav: file a new bug (and reference this one)

only drivers can set block flags
Flags: blocking1.5+
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: