Description of problem: BZ provides couple of (custom) fields that allow entering multi-line text, such as Environment or Technical Notes, few more for specific products. BZ does not seem to enforce what endlines should be used in those fields (\n vs. \r\n), which results in confusing endline-only changes when using both xmlrpc and web ui, as well as xmlrpc clients getting unexpected endlines. Steps to Reproduce: 1. Set multi-line text to one of the fields, such as "line1\nline2\nline3\n" 2. Open the bug in webui and do some change (add comment, change state, add cc, ...) without changing that multi-line field. This can be done on Linux using firefox, does not need to be done on the platform that uses \r\n natively. 3. Check history of the bug, see it notes field change, though you can't really figure out what the change was from the webui. 4. Fetch field value using xmlrpc. See that it now contains unexpected \r. Expected results: BZ should one endline type internally, and convert endlines on input/output as needed. E.g. if \n is to be used internally, BZ should do \r\n -> \n on the data it receives from the web browsers to avoid confusing whitespace-only changes. If \r\n is chosen to be used internally, BZ should do \n -> \r\n on xmlrpc inputs and \r\n -> \n on xmlrpc outputs. Working around in xmlrpc clients is possible, but sounds like a wrong place to fix this.
I've changed Environment using xmlrpc (Bug.update) and now the value is: 'cf_environment' => 'line1 line2 line3', Adding this comment via webui, without touching Environment field.
History now tracks I did change Environment: https://bugzilla.redhat.com/show_activity.cgi?id=735914 and the value is: 'cf_environment' => 'line1^M line2^M line3',
As part of the recent Bugzilla 2.4 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time. If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically. Thanks, the Bugzilla team.
As part of the recent Bugzilla 4.2 upgrade the Bugzilla team are cleaning up bugs opened against old versions of Bugzilla. This bug has been flagged as an old bug and will be CLOSED WONTFIX in 7 days time. If you believe this bug is an issue in the latest Bugzilla version please comment on this bug within 7 days. Doing so will ensure this bug is not closed automatically. Thanks, the Bugzilla team.
Similar to comment #2, I changed Environment using xmlrpc and adding this comment via webui without touching Environment. It should result in the \n -> \r\n of the field (it did in partner-bugzilla).
These bugs have been flagged as still relevant and are being reset to default values for PM consideration.
Definitely a problem. Not sure if the best solution is to change the input from RPC, or ignore ^M when considering if a field is changed. I'm going to submit this upstream for their opinion. My preference is for the second option. -- simon
(In reply to comment #7) > My preference is for the second option. No, it's actually for the first option now :)
I've submitted a patch upstream (review pending) to sanatise the newlines for multi line fields. With the patch \n will get converted to \r\n on input. Web browsers submit data as \r\n so with this change any data coming from XMLRPC with \n newlines will be sanitised to match the browser data.
This has been approved upstream, and will be part of our Bugzilla 4.4 release.