fix: trim vCard name fields on import to fix mis-sorting#574
Open
MiMoHo wants to merge 1 commit into
Open
Conversation
VcfImporter stored structured-name components verbatim from ezvcard, so a vCard whose given-name field had a leading space was imported as " John". normalizeString() strips only diacritics (not whitespace), and compareUsingStrings orders any value whose first character is not a letter after all A-Z names, filing the contact after "Z". The contact editor already trims these fields via the commons EditText.value extension; this matches that behavior by trimming the structured-name components at import, fixing sorting, the fast-scroll bubble, and business-contact detection.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Type of change(s)
What changed and why
VcfImporterstored the structured-name components (given,family,additionalNames,prefixes,suffixes) and the nickname verbatim from ezvcard, without trimming. A vCard whose given-name field has a leading space (e.g.N:Doe; John;;;) was therefore imported asfirstName = " John".That corrupts the sort key:
Contact.compareTobuilds it withfirstName.normalizeString(), andnormalizeString()only strips diacritics via NFD normalization, not whitespace.compareUsingStringsthen deterministically orders any value whose first character is not a letter (a leading space;' '.isLetter() == false) after every A-Z name, so the contact files at the very end, after "Z". The contact still displays as "John" becausegetNameToDisplay()trims, which is exactly the confusing symptom the reporter described. The fast-scroll bubble (getBubbleText(), which returns the raw first name) is affected too.The contact editor already trims these fields when saving, through the commons
EditText.valueextension (text.toString().trim()). This change makes VCF import match that convention by applying?.trim()to each structured-name component at import time. For a null component the safe-call short-circuits and the elvis yields"", so behavior is unchanged for absent fields; for" John"it yields"John". One place fixes sorting, the fast-scroll bubble, and business-contact detection.Tests performed
Built the
fossDebugvariant and verified on an Android 15 (API 35) emulator:Imported a vCard whose given name had a leading space (' John'); sorted by First name. 'John Doe' filed correctly under 'J' between 'Amy Adams' and 'Zack Zulu', avatar shows 'J', fast-scroll index shows A/J/Z (no blank / bottom placement). Name trimmed on import.
Also confirmed
detekt,lint, unit tests and the build all pass locally (CI-equivalent).Closes the following issue(s)
Checklist
CHANGELOG.md(if applicable).Coded with Opus 4.8 ultracode.