This looks like it has been investigated fully. moving to done.

Moving this back to verification because we didn't actually sit down as discussed to go over what the overall desired enstate should be.

I think I know the answer to one question: why does this issue only affect the data type string, not e. g. external ID or URL? Because string is the only data type we parse in JavaScript.

For every other data type, we parse the value in JavaScript by sending it to the wbparsevalue API and thereby calling the PHP parser. The PHP parser for strings is fairly simple, but one thing it does is remove leading and trailing whitespace, such as the \r\n that are causing the problem. (Another thing it does is Unicode normalization.) The JS parser doesn’t do this, so when the Wikibase frontend tries to send a string value that was parsed in JS (and therefore still has the \r\n) to the backend, there’s an error because the whitespace should have been removed. My proposed solution is to stop using the JS StringParser and parse strings via PHP too, like all other data values.

I have some idea about another question: why does this issue go away if you add and remove a space elsewhere in the string? Because ValueView already removes line breaks from the input.. It subscribes to the eachchange event and replaces all line breaks (DOS or Unix) with the empty string. Then why does the bug exist at all? That’s the part I don’t understand… at the HTML level, the \r\n is gone immediately after paste, but I guess it must be persisted somewhere in JS until the next time the input changes.