Unable to resize Notes Field

[Sjoerd001]

Describe the bug

I used to resize the notes field, but now it is one input filed and data shows as a one-liner.

Steps to reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

Resize field to see the actual info

Actual behavior

Hole note shows as a one-liner

Contact version

7.2.4

Operating system

No response

PHP engine version

PHP 8.4.10

Web server

Apache (supported)

Database

MariaDB

Additional info

Not really shure if its an contacts bug or some background issue in nextcloud.

[jancborchardt]

Can’t reproduce this specific issue with the latest stable. However, the notes field does need to be manually resized, and it would be much better if it uses autosize to always adjust to the content within.

EDIT: Opened separate issue at https://github.com/nextcloud/contacts/issues/4614

[formwandler]

I can confirm this as an issue (bug) after one of the latest updates of NC and the contacts app (maybe within last 2-3 months).

It occurs only with existing contacts with multi-line notes. After update of NC and/or contacts app, the previous multi-line field became single-line field. No chance to extend by pressing "enter". And no chance to get it back to multi-line in UI at all.

New entries are fine in UI - also after storing the record.

See screenshot of edit mode of old data being corrupted after update:

I am running Nextcloud Hub 10 (31.0.8) with Contacts 7.2.4.

See also https://help.nextcloud.com/t/notes-field-is-single-line-only-in-aio-11-4-0-contacts/229434

[Sjoerd001]

After exporting(Download) one vcard and editing the lines:

BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 4.5.7//EN
.....
REV:20250815T195004Z

into:

BEGIN:VCARD
VERSION:4.0
PRODID:-//Nextcloud Contacts v7.2.4
....
REV:VALUE=DATE-TIME:20250815T195004Z

After deleting the old one in my addressbook and import the changed vcard i get the proper Notes-Field back.

But with a lot of old contacts the is undoable and needs some automation for the next update maybe?

[Sjoerd001]

By using phpmyadmin and changing the data in the oc_cards.carddata (longblob) from version 3.0 to 4.0 looks to solve this issue. But Downloading(exporting) saves it as version 3.0 again. So importing it wil bring you to the same problem as reported.

[michaeldaly600]

Bug Summary: vCard Import Fails with Multi-line and Escaped NOTE Fields

Description

Nextcloud Contacts fails to import otherwise valid vCard 3.0 files when they contain multi-line NOTE fields (with escaped \n) and/or when those lines are folded per the vCard specification (RFC 2426 / RFC 6350).

The same .vcf files are accepted by other vCard-compliant software (e.g., Apple Contacts, Thunderbird), suggesting the issue is in Nextcloud’s vCard parsing/validation logic.

Observed Behavior

• Simple vCards with short NOTE fields import successfully.
• More complex vCards containing long NOTE text, escaped newlines (\n), and proper line folding (\n continuation) are rejected silently or cause a generic “import failed” error.
• Example failing entry (valid according to spec):

BEGIN:VCARD
VERSION:3.0
PRODID:-//MailClient.VObject/10.3.1567.0
UID:43a35a25-a751-4b3d-b884-979ddf8d0f94
REV:20250420T144843Z
N:GFM accountants;/docs folder access;;;
FN:/docs folder access GFM accountants
NOTE:Document access instructions:\n/usr/bin/htpasswd -bc /usr/local/etc/wwwpasswd doc
 umentaccess XXXX\nThen restart apache.
END:VCARD

This vCard is valid because:

• Line length is ≤ 75 characters per RFC, with correct folding (continuation lines begin with a space).
• Escaped newlines (\n) are allowed in NOTE values.
• No illegal characters or missing required fields.

Yet it fails in Nextcloud.

Expected Behavior

• Nextcloud should successfully parse and import spec-compliant vCards, including those with folded lines and escaped newlines in NOTE or X-ALT-NOTE fields.

Impact

• Large imports containing detailed contact notes fail.
• Users are forced to simplify or truncate NOTE fields to complete import, leading to loss of data fidelity.

References

• RFC 6350 (vCard 4.0) — section 3.2 (line folding), section 3.3 (character escaping)
• RFC 2426 (vCard 3.0) — equivalent rules apply

---

[Sjoerd001]

+1

Seems so quiet at the nextcloud developers.

Imported your test .vcard about /docs and it 's a one line for the notes field. Its just a messy one-liner blob: Document access instructions:/usr/bin/htpasswd -bc /usr/local/etc/wwwpasswd documentaccess XXXXThen restart apache.

@formwandler Thanks for the link

[formwandler]

Bug Summary: vCard Import Fails with Multi-line and Escaped NOTE Fields

Description

Well, maybe this is related to the same root cause, but the original bug is that stored data of existing NC installations got corrupted or even displaying in UI is broken after a recent change in the contacts app or NC (without any importing of data). Hope to get a fix or bulk procedure to recover the notes data without recovering whole contacts DB tables.

So, maybe worth to split these issues. NC developers should decide how to go on.

[SebastianKrupinski]

@michaeldaly600

If your issue is related to importing then please open a new issue ticket.

[SebastianKrupinski]

Hi Everyone,

We have not had time to look in to this issue yet, as we are working hard on some major features for the upcoming NC release and foundational upgrades to the contacts and calendar app.

We will have a better look at this after the dust settles from the upcoming releases.

[marneu]

seems duplicate in #4614 and should go together with #4613

[ronaaron]

I also just noticed this after a recent update. Tried using \n and \r\n still only get a single line

[Sjoerd001]

Seems duplicate #4656

[GVodyanov]

Hello! Could you please check whether this is still an issue? We implemented https://github.com/nextcloud/contacts/pull/4679 in the meantime

[ronaaron]

As of ver 31.0.9 yes, it's still an issue.

[GVodyanov]

As of ver 31.0.9 yes, it's still an issue.

Could you please specify the version of the contacts app you are running?

[ronaaron]

7.3.1

[formwandler]

I updated to 7.3.1 and I can confirm that it's still an issue for me (NC 31.0.9).

The notice field is still no textarea for existing contacts (but just one line without line feeds).

[Sjoerd001]

Same here (7.3.1 and NC 31.0.9)

Only change i see is that manually resizing the note is gone and the width of the note is not wider then 32 characters.

New contacts created gets an auto-resized field of about 30 characters wide, but exporting then deleting and re-import changes everything to again ... a one-liner input field.

[SchorschKloni]

In 8.04 it is still an issue with old contacts. All new Contacts are working. Any idea how i can solve it on my own?

[formwandler]

This is still the most annoying bug currently on my Nextcloud system, since I use the notice field heavily. Hope that - after the new major NC release is out since weeks - someone is working on it. I am open for doing some testing.

[Sjoerd001]

Its an import/export problem.

See my comment on bug: https://github.com/nextcloud/contacts/issues/4656#issuecomment-3489356129

[formwandler]

Its an import/export problem.

See my comment on bug: #4656 (comment)

Well, my contacts are broken without being exported/imported. The notice field of existing contacts is broken just after update of NC and/or the contacts app.

[Sjoerd001]

Well, my contacts are broken without being exported/imported. The notice field of existing contacts is broken just after update of NC and/or the contacts app.

Thats because they are still stored in the old format. Thats why I thought it wil be converted when I export a card and then import it again, but there is no conversion into the new database format.

Devs have some more work to do.

Im just testing and try to figure out what goes wrong the best I can and understand. Im not a coder .

BTW: Old picture/avatar also seems some update to V4.0 V3.0 version has as PHOTO:

PHOTO;ENCODING=b;TYPE=PNG,PNG:

While V4.0 uses:

PHOTO;TYPE=PNG;VALUE=URI:data:image/png;base64\,

So simply changing V3.0 to V4.0 in your .vcf file will not work if thats not also changed. And im not going to change every card manually.

[SchorschKloni]

Its an import/export problem.

I dont use import or export @all . So SQL query can solve this for me. Can you share your query with me?

[Sjoerd001]

No you cant use SQL to change the cards. Simply change V3 to V4 corrupts the avatar/pic. The PHOTO: line needs to be completely base64 reformatted. The only way I see is writing some script that will do that for you. I cant do that.

The devs can do that.

[formwandler]

I was able to change an old contact in database directly to fix the notice field corruption and to remain also the photo.

What I changed (in the blob by replacing the whole blob with a prepared text):

1. VERSION:4.0

2. Replace the header information in the photo from something like

PHOTO;ENCODING=b;TYPE=image/jpeg;VALUE=BINARY:

to e.g.

PHOTO:data:image/jpeg;base64,

As stated by @Sjoerd001 and also tested by myself, export and re-import as VCF does not help to clean the corrupted contacts, since import of even new contacts break the notice field again. So, definitively something that must be fixed in code.

Apart from fixing the code we could now at least fix corrupted contacts by a "bulk-replace" script (with pattern matching, since the photo string is not always same in V3), even though it's more complicated with a blob, I think ... and should be tested carefully.

Any progress here, @SebastianKrupinski ?

[andreas51]

I'm experiencing the multi line note field issue for some of my contacts (NC 32.0.1, Contacts 8.1.0). I noticed that all vcards of problematic contacts have the version in line 2 directly after BEGIN:VCARD. If there is at least one other attribute before the version line, the note field works as expected.

For example, downloading and deleting a contact with a broken note field, then switching line 2 and 3 in the downloaded vcard file and finally re-importing it fixes the note field issue for that contact. Editing the contact with another application that restores the previous order on save will break it again.

Example:

• Start of vcard with a broken multi line note field: BEGIN:VCARD VERSION:3.0 UID:1c853f3e-c52e-11f0-823f-ff1ddbfe0aff ...
• Start of vcard with a correctly working multi line note field: BEGIN:VCARD UID:1c853f3e-c52e-11f0-823f-ff1ddbfe0aff VERSION:3.0 ...

Can anybody confirm this behaviour?

[Sjoerd001]

@andreas51 That seems to do the trick for my 300+ exported contacts. (Still evaluating the results, but seems promising even for the avatars/images) @formwandler @jancborchardt

@SchorschKloni Sorry no sql statements for MySQL But maybe underlying awk script can give some solution.

Asked chatgpt for a solution:

/^BEGIN:VCARD/ {
    inside = 1
    uid = ""
    delete lines
    next
}

inside && /^UID:/ {
    uid = $0
    next
}

inside && /^END:VCARD/ {
    print "BEGIN:VCARD"
    if (uid != "") print uid
    for (i = 1; i <= length(lines); i++) print lines[i]
    print "END:VCARD"
    inside = 0
    next
}

inside {
    lines[length(lines)+1] = $0
    next
}

{
    print
}

✅ How it works Lines inside a vCard are stored in an array instead of printing immediately. When END:VCARD is reached: Print BEGIN:VCARD Print UID (if exists) Print all other lines in original order Print END:VCARD Multiple vCards are handled independently. UID always moves immediately below BEGIN:VCARD. ▶️ One-liner version (GNU awk safe)

awk '/^BEGIN:VCARD/ {inside=1; uid=""; delete l; next} inside && /^UID:/ {uid=$0; next} inside && /^END:VCARD/ {print "BEGIN:VCARD"; if(uid!="") print uid; for(i=1;i<=length(l);i++) print l[i]; print "END

NO WARRANTIES APPLY HERE. So backup,backup,backup FIRST

NOTE: to be fully compatable with say windows change print to printf and add add \r\n at the end. I ended up with a changed file with exactly the same size.

[formwandler]

@andreas51 That seems to do the trick for my 300+ exported contacts. (Still evaluating the results, but seems promising even for the avatars/images) @formwandler @jancborchardt

Yes, moving UID before VERSION before importing does the trick, but a fix is still needed since this is only a temporary solution by a dirty trick on user side.

[jancborchardt]

I still get this overlap on daily in the autosized field @GVodyanov: