Multiline field text from Google Contacts via CalDAV shows up cluttered with additional "\r" linefeed marks
Categories
(Thunderbird :: Address Book, defect, P2)
Tracking
(Not tracked)
People
(Reporter: rainer.meier, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
Added Google and Nextcloud address book to Thunderbird.
Actual results:
Google seems to store Notes on vCards with Windows linefeed (\r\n). All notes in my google contacts were showing up like this:
"note line 1\r
note lin 2\r
"
This did not happen do contacts in Nextcloud address book.
Note: I do sync the notes to google using "Go Contact Sync Mod" which might lead to "Windows-encoded" contents. However Google web interface is displaying the notes correctly. Only Thunderbird seems not to expect "\r" in linefeeds.
Expected results:
Thunderbird correctly accepting all common line break styles:
\r
\n
\r\n
Updated•3 years ago
|
Updated•3 years ago
|
Comment 1•3 years ago
|
||
I reckon this isn't about the line ending at all, but Google's broken extra escaping of text fields, AKA bug 1777920. If there's a \r
in the field and it's escaping it as \\r
, that will cause it to appear in our UI.
Reporter | ||
Comment 2•3 years ago
|
||
So now the question is if this is just blamed on Google and users are left suffering from the issue or Thunderbird implementing a google-specific workaround. Does anyone know if this is reported/known to Google? I did not find any reference.
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Pulling all of these bugs into one place.
I think you'll find the \r
characters come from Outlook (that's what Go Contact Sync does, right?) not that it matters. As for reporting it to Google, I very much doubt they want to know.
Reporter | ||
Comment 4•3 years ago
|
||
Not sure if Go Contact Sync does add anything here or adds to the behavior. In fact the Google web GUI does not display any additional charactors. Also latest TB 102.02 seems to have resolved it on display-level.
Description
•