Closed Bug 92500 Opened 23 years ago Closed 22 years ago
Web browser "corrupts" params file with hard returns (^M)
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 recipient) 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 templates.
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) 'newchangedmail_body' 'passwordmail_body' 'voteremovedmail_body' 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: firstname.lastname@example.org 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.
This is going to be a blocker for the 2.16 release
Severity: normal → blocker
Would this do the trick? Gerv
Status: NEW → ASSIGNED
Comment on attachment 57552 [details] [diff] [review] Patch v.1 Looks good!
Comment on attachment 57552 [details] [diff] [review] Patch v.1 Looks good to me.
checked in. /cvsroot/mozilla/webtools/bugzilla/doeditparams.cgi,v <-- doeditparams.cgi new revision: 1.16; previous revision: 1.15
Status: ASSIGNED → RESOLVED
Closed: 22 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.