Problem with newline characters CRLF in Editor

Uni-Bamberg

Hey,
I'm using DataTables editor v2.3.2 with inline editing. I've one field with multiline text containing newline characters as CRLF configured as "textarea". My problem is: everytime I go to editing this field (text will transform to inline textarea) it determines a change - nevertheless I've nothing changed - and sends a patch. Analysing this problem took me to newline characters stored in my database as CRLF (\r\n). But it sends only LF (\n).

How can I get rid of this behaviour? Is there any setting to set newline characters? Why are they transformed from \r\n to \n?

Here are some code snippets from my setting:

var editorPartialPatch = new DataTable.Editor({
ajax: {
url: '/projects/bulkedit/updateobjectfull/{id}',
type: "PATCH"
},
fields: [
{
label: 'Id:',
name: 'id',
readonly: true
},
{
label: 'Project:',
name: 'project',
readonly: true
},
{
label: 'Name:',
name: 'name'
},
{
type: 'textarea',
label: 'Beschreibung:',
name: 'description'
},
{
label: 'Type:',
name: 'type',
readonly: true
}
],
formOptions: {
inline: {
fieldInfo: true,
onBlur: 'submit',
submit: 'allIfChanged'
},
},
idSrc: 'id',
table: '#searchTable'
});

editorPartialPatch.on('submitSuccess', function ( e, json, data) {
toastr.success("Die Änderungen wurden gespeichert");
});

var searchTable = $('#searchTable')
.DataTable(
{
rowId: 'id',
columns: [
{ data: 'project' },
{ data: 'id' },
{ data: 'name', className: 'editable' },
{ data: 'description', className: 'editable' },
{ data: 'type' },
{ data: 'subtype' },
{ data: 'abbreviation' },
{ data: 'datecreated' },
{ data: 'datemodified' },
{ data: 'version' },
{ data: 'owner' },
{ data: 'path' }
],
order: [[0, 'asc'], [2, 'asc']],
keys: {
columns: '.editable',
editor: editorPartialPatch
},
buttons: [
{
extend: 'selected',
text: '<i class="fas fa-up-right-from-square mr-2"></i>Details',
action: function(e, dt, node, config) {
var row = searchTable.rows({ selected: true }).data()[0];
showObjectInfoModal(row.id,getMstrIdInBrackets(row.project), getNumberInBrackets(row.type));
},
enabled: false,
className: "btn-primary"
},
{
extend: 'selected',
text: '<i class="fas fa-code-branch mr-2"></i>Abhängigkeiten',
action: function(e, dt, node, config) {
var row = searchTable.rows({ selected: true }).data()[0];
showSearchUsesModal(row.id, getNumberInBrackets(row.type));
},
enabled: false,
className: "btn-primary"
},
{
extend: 'selected',
text: '<i class="fas fa-code-merge mr-2"></i>Komponenten',
action: function(e, dt, node, config) {
var row = searchTable.rows({ selected: true }).data()[0];
showSearchUsedByModal(row.id, getNumberInBrackets(row.type));
},
enabled: false,
className: "btn-primary"
}
]
});

allan

Hi,

I don't believe that this is a bug in Editor, but rather how the browser handles carriage return characters.

I've created this little test case to check it: https://live.datatables.net/jicayuri/1/edit . As you'll be able to see I create a text area and then write a short string with \r\n into it.

However, when reading back the \r has been stripped.

I'm using Firefox on OpenSUSE for this check, but I believe the outcome is the same on Windows and Mac as well.

The HTML spec says:

It is normalized so that line breaks use U+000A LINE FEED (LF) characters.

So what you are seeing is expected based on the HTML spec.

If you need \r\n in the database data, what you could do is use a set formatter on the server-side for the field to replace \n with \r\n.

Regards,
Allan

Uni-Bamberg

Hi Alan,

I've done some tests and you are correct. The problem with textarea is, that .val() transforms line breaks to \n. But sending data with fetch, XMLHttpRequest and FormData will preserve line breaks with \r\n. Thats weird.

As workaround I had to transform every CrLf (\r\n) to \n on server side during load and after POST back from \n to \r\n to preserve original encoding.

Please change my Title from Bug to Problem.

Thx

allan

Hi,

But sending data with fetch, XMLHttpRequest and FormData will preserve line breaks with \r\n. Thats weird.

That's interesting. I suspect that if it is sending the data read from the form then it is probably "re-normalising" the line breaks to \r\n! Possibly it does that depending on the platform, or content type.

Allan