208944 - No recipient addresses found in header Email sent to

Status: RESOLVED INVALID

(Bugzilla :: Administration, task)

Description

[Daniel]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Linux 2.4.19 i686) Opera 7.11  [en]
Build Identifier: 

This is the same as bug: 89211 and 92500 which I would have reopened, but 
couldn't. If I edit the preferences using Opera's browser, I will get the error 
mesage: "No recipient addresses found in header Email sent to"
and a list of the email addresses underneath. This has been a problem even since 
Bugzilla 2.14x

Reproducible: Always

Steps to Reproduce:
1. Go to parameters using the Opera browser
2. Edit (possibly not necessary) a little bit of the emails that go out.
3. Submit changes
4. Make a change to a bug and hit submit

Actual Results:  
Changes submitted for bug 1542

 No recipient addresses found in header No recipient addresses found in
header No recipient addresses found in header
 No recipient addresses found in header  Email sent to:
[e-mail], [e-mail],
 [e-mail], [e-mail],


Expected Results:  
Just sent the email with no complaints.

I've only ever seen this happen with Opera.

Comment 1

[Daniel]

I should perhaps point out that I'm using Bugzilla Version 2.16.3 

Comment 2

[Florin Mihut]

I have the same problem with just small differences: I use Opera Version
6.03 Build 219. I can add supplementary things about the bug: once I had this 
problem the only way to escape of it was to reinstall bugzilla (I tried to run 
checksetup script, to delete the database from MySQL and run again checksetup, 
etc ... no use).

Comment 3

[Vlad Dascalu]

I can confirm it, changing to NEW. 
 
The issue is reproductible only with Opera 6, I've tested this on Opera 7 and it 
works ok. 
 
The problem is that editparams.cgi uses a special encoding for "\n" in order to 
separate lines during sections like "newchangedmail". So instead on having 
one line per row, all the content of the template for emails is added on a single 
row. 
 
I'll attach a screenshot. 

Comment 4

[Vlad Dascalu]

Attachment: Describes how Opera 6 puts everything in one row instead of multiple rows.

Comment 5

[Vlad Dascalu]

I'll add that the URL in the screenshot, loaded in other browsers (except Opera 
6), renders perfectly okay, with only 1 line/row, the way it should be. 

Comment 6

[Vlad Dascalu]

The delimiter used in the source of editparams.cgi is 
 , I think that dates 
back to bug 82809 comment #6 . 

Comment 7

[Vlad Dascalu]

*** Bug 202525 has been marked as a duplicate of this bug. ***

Comment 8

[Vlad Dascalu]

#202525 's initial post has described the problem very good, so I'm reposting it
here in order to have everything in one place.

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.0; UNIX) Opera 6.1  [en]
Build Identifier: 

When I edit bugzilla parameters with opera, the multi-line
fields such as the mail templates are displayed as a single
long line.  When I view the source that opera think's it's
displaying, it shows the &#13 identifiers for a raw CR.

If I then click "save edits", even without changing
anything, bugzilla reports that passwordmail, newchangedmail,
whinemail, voteremovedmail, and browserbugmessage are all
changed.

If I then look at the new value of data/params, all of
these fields have become a single-very long line.  Naturally,
this screws up the sending of bug-email.

To edit the preferences safely, I used IE, although I expect
other browsers might have worked as well.

This seems to be related to bug 92500 and bug 97980 and
perhaps others.

I will attach the html that opera gets for the editparams.cgi
page, as well as the before and after versions of data/params.

This could very well be a bug in opera, of course, although I
have used opera to edit multi-line text-boxes and things seem
to have gone ok then.




Reproducible: Always

Steps to Reproduce:

1. start opera and log into bugzilla as the administrator
2. click on the "parameters" link.
3. click on "submit changes".


Actual Results:  
data/params is now corrupt.  All of the multi-line fields
in it are very long single lines.

(reported by [e-mail] (Dale Hagglund) , check bug 202525 for some
interesting attachments).

Comment 9

[Daniel]

> The issue is reproductible only with Opera 6, I've tested this on Opera 7
> and it works ok.

Vlad, please notice that the bug was filed using Opera 7.11 for Linux.
That's the browser, including version I encountered the problem with.

Comment 10

[Vlad Dascalu]

Daniel, I've used Opera 7.1.0-2003-04-10, and I can't reproduce the problem.

Could you take a look at the attached screenshot and tell if with your browser,
the lines appear like that on only one row, or each line has its own row?

Comment 11

[Vlad Dascalu]

(either way, it's reproductible with Opera 6 as stated above)

Comment 12

[Daniel]

I tried, but I don't see any problems with opera 7.11 ignoring the newlines. 
(ie. everyline does have it's own row)

unfortionatly, this is a production machine, and I'm not at liberty to try to 
break it to find the bug again.

Comment 13

[Dave Miller [:justdave]]

Vlad: we had this same issue with Konqueror a while back (you might be able to
find the bug on it - I don't remember how we resolved it [FIXED, INVALID,
WORKSFORME or whatever]) but it ended up being a bug in Konqueror's form
handling, and they did fix it in Konqueror.  I suspect Opera has the same issue
(lack of reproducibility in the newer versions may indicate that they've fixed
this already).

Comment 14

[J. Paul Reed [:preed]]

Just FYI, bug 84876 works around this problem by making those mail templates not
params anymore (since they shouldn't be); see also bug 100089.

Suggest WONTFIX.

Comment 15

[Dave Miller [:justdave]]

This is very definitely (from reading the bug) a bug in the browsers affected,
and I can't think of any way we could possibly work around it.

There are things in the works that will cause the mail to get tripped up faster
if it happens, but the more general problem with the textareas on the params
page losing their newlines isn't something we can do about without those
browsers getting their bugs fixed.

Marking this invalid as "yes, it's a bug, but the bug isn't in Bugzilla"