365790 - request mail comments have ^Ms (CRs, carriage returns) sometimes

Status: RESOLVED DUPLICATE of bug 486206

(Bugzilla :: Email Notifications, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Since the Bugzilla upgrade to pre-3.0 on bugzilla.mozilla.org that took place on December 26, *some* of my request mail has had the *comment* part of the request using CR-LF line terminators instead of standard LF line terminators.  This shows up in my mail client (mutt), but I suspect it doesn't in most GUI mail clients.

I've had this problem in request mail coming from Bernd <[e-mail]> and from Robert Longson <[e-mail]>; I suspect in both cases they cut and pasted into the comments field of the create attachment or edit attachment dialog.  (I've seen it in a "review granted" mail from Bernd, which must use the edit attachment dialog; I think the example below comes from the "create attachment" dialog based on "View Bug Activity".)  I haven't seen it in mail from anyone else.

For example, with the CRs shown as "^M", the mail message body begins like this:

======
Robert Longson <[e-mail]> has asked David Baron <[e-mail]>
for review:
Bug 264132: Implement fallback for SVG paint servers
https://bugzilla.mozilla.org/show_bug.cgi?id=264132

Attachment 250343 [details] [diff]: address review comments
https://bugzilla.mozilla.org/attachment.cgi?id=250343&action=edit

------- Additional Comments from Robert Longson <[e-mail]>
(In reply to comment #11)^M
> (From update of attachment 248635 [details] [diff] [review])^M
^M
> Why black rather than SetNoneValue() ?^M
^M
As per bug 354295 Opera/Safari default to black if the URL is invalid to make
it easier to spot. Note that as far as I can tell Opera does not seem to
support fallback colours for stroke. I've therefore left the code defaulting to
black if no fallback is specified.^M
^M
> So I think this should be simplified to something like:^M
=====

Comment 1

[Robert Longson [:longsonr]]

Here's what I did... 

I clicked on the reply button in bugzilla which got me the text I wanted in the Additional Comments field. Since I wanted to edit this to include with an attachment I then went to create an attachment in another tab and copied and pasted the reply text from the first tab into the Comment field of the attachment. All this in firefox running under Windows XP.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

This sounds like it may be a duplicate of bug 365713.

Comment 3

[Bernd]

> I suspect in both cases they cut and pasted into the comments field of the 
> create attachment or edit attachment dialog. 
Thats exactly how I did that, 
FF WinXP (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/2006122504

Comment 4

[Max Kanat-Alexander]

It's possible that attachment.cgi needs to use Bugzilla::Bug->_check_comment to remove the CRs and generally fix things, instead of whatever it's using now.

Comment 5

[Frédéric Buclin]

The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.

Comment 6

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).