Closed Bug 92500 Opened 23 years ago Closed 23 years ago

OmniWeb browser "corrupts" params file with hard returns (^M)


(Bugzilla :: Administration, task, P1)




Bugzilla 2.16


(Reporter: streib, Assigned: gerv)




(1 file)

When updating parameters using the OmniWeb web browser for Mac OS X, the browser
apparently submits hard returns (^M) instead of newlines for textarea stuff.  So
for example, I get a hard returns in the newchangedmail headers after the
"From:" header which makes sendmail (8.11.4) barf (it thinks there's no

See also bug report 89211 which helped me solve the error, and now I know where
it's coming from.

Not sure if this is considered a browser bug or a Bugzilla bug, but it would be
a quick fix to doeditparams.cgi to strip these out (looks like it's already
translating \r\n to \n).
I think this is related to another bug, but I'll leave it here for now until we 
get a little closer to 2.16 on triage :)

I use Omniweb and have run into this on other browsers besides Omniweb also, so I 
think this is at least partially a Bugzilla problem.  I know CR-delimited is 
legal according to the w3c spec.
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.16
*** Bug 92409 has been marked as a duplicate of this bug. ***
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
Version: Bugzilla 2.12 → 2.10
Changed comment since this bug is showing up in my query for OS X Mozilla bugs
Summary: OmniWeb browser "corrupts" params file with hard returns (^M) → Bugzilla Bug, not Mozilla bug - OmniWeb browser "corrupts" params file with hard returns (^M)
I can't read the whole summary in the buglist if you do that.  Try limiting your
query to the Browser product if you only want Mozilla bugs.
Summary: Bugzilla Bug, not Mozilla bug - OmniWeb browser "corrupts" params file with hard returns (^M) → OmniWeb browser "corrupts" params file with hard returns (^M)
correcting version field lost in product move
Version: 2.10 → 2.13
*** Bug 89211 has been marked as a duplicate of this bug. ***
Just to confirm,
same happened to me using Opera 5.0 on Linux (Bugzilla 2.14), perl 5.61.
To be really safe, newchangedmail and passwordmail should be seperated
into seperate fields (it's too easy to screw up the mail templates).
I guess I'm not the first to propose that.
Florian: not sure what you're suggesting here.  Those two mail fields are
already separate??
I think that might mean two different pages.

We might want to templatise these email parameters for 2.16 and skip fixing this
directly.  Admins would lose the ability to edit it online but I don't think
that's a major problem - if it was we could provide a facility to edit all
I wanted to suggest that the param 'newchangedmail' itself would be split
up into seperate params 'newchangedmail_from', 'newchangedmail_body' et al.

Also, the same 'from'-Param could be used for all mail types (now you have to
change 'bugzilla-daemon' three or four times).

Something like:
'automatic_from_address' - 'From:'-Field for generated mails (processmail)

I dont think you'd need to fiddle with the 'To:' field at all?

But I guess it would not be flexible enough any more?
Yeah, the To: field gets fiddled with constantly on the test sites...

For example, if you're testing something, and needed to see what the email
looked like, but didn't want mail to go out to all your users, you could make
your header look like this:

To: my@email.address
X-Real-To: %to%

Then the mail would all go to you, but you'd have a header telling you who it
would have gone to.
OS: MacOS X → other
This is going to be a blocker for the 2.16 release
Severity: normal → blocker
Attached patch Patch v.1Splinter Review
Would this do the trick?


Assignee: justdave → gerv
Keywords: patch, review

Comment on attachment 57552 [details] [diff] [review]
Patch v.1

Looks good!
Attachment #57552 - Flags: review+
Comment on attachment 57552 [details] [diff] [review]
Patch v.1

Looks good to me.
Attachment #57552 - Flags: review+
checked in.

/cvsroot/mozilla/webtools/bugzilla/doeditparams.cgi,v  <--  doeditparams.cgi
new revision: 1.16; previous revision: 1.15
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.