Closed Bug 1786677 Opened 3 years ago Closed 2 years ago

label "Other" not supported in address book

Categories

(Thunderbird :: Address Book, defect)

Thunderbird 102
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: wrhenshaw99, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36

Steps to reproduce:

I am using CardDAV to sync with my Google contacts. With version 102.2.0 the contact labels seem to now be working fine when editing a contact.

I edited a contact and expected the labels on addresses, emails, etc. to match what is in Google Contacts.

Actual results:

They all seem to match except those with a label of "Other" in Google contacts. these get converted in Thunderbird to None which is not correct. "Other" is a valid Google contact label.

Expected results:

If the label in Google contacts is "Other" it should be "Other" not "None" in Thunderbird.

Component: Untriaged → Address Book
Blocks: 1771576

We follow the VCard specs to be complaint with those, and the extra field for any other info is called "Notes", therefore Thunderbird is using the correct string and Google decided to name that field "Other".
There's no loss of data of functionality, simply Google is not respecting the VCard standard labels.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID

As Google mail and contacts are one of (if not the most) used mail programs and contact lists used in the world, wouldn't it make sense to at least cater for what they use? Wouldn't it make more sense to at least show that there is a value rather than display it in the TB address book as a blank field as if Google doesn't have a label for that field? Since TB has maybe 5% of the market (or less) it seems a bit weird to just ignore Google's label.

Bill

https://datatracker.ietf.org/doc/html/rfc6350#section-5.6
At least for exporting a contact as vcard, if it's set to "Other" the type is simply omitted by google. None matches that.

Thanks for the reply. I'm a bit confused. Are you saying that when you use CardDAV to sync Google Contacts to the TB address book that Google doesn't pass the "Other" label to TB?

Bill

Correct. Just checked with CardDAV as well. Other is treated as unlabelled.

Thanks again for the reply. I guess I'm surprised. Cardbook doesn't have any problem getting the label Other from Google and displaying it in its address book. I was hoping to use the new functionality of CardDAV address book syncing in TB, but I guess I'll have to go back to Cardbook.

Bill

I'd assume all it does is say Other instead of None in the UI. What I'm saying is, they are the same.

The thing is that TB isn't actually displaying it as "None", it is displaying it as blank.

Cardbook displays whatever the label is in Google. If I set the label to "YYYYY" in Google and then sync it to Cardbook, then Cardbook displays it as "YYYYY", not "Other". Same for "Other"... if that is the label in Google, then that is what Cardbook shows.

By displaying it as blank, TB is making it appear as if there is no label in Google. This could lead someone to apply a label in TB thinking there wasn't one and that would override the correct label in Google.

Bill

When you set it to something random in google, like YYYYY it set it as a label (but not TYPE). For "Other" it just leaves out out.

I don't know about label vs type. I am not a programmer and don't know the inner workings of CardDAV.

All I know is that in Google if the phone numbers are shown like this:

111-222-3333 Work
111-222-3334 Home
111-222-3335 Other
111-222-3336 YYYYYY

Then in Cardbook they show like this:

111-222-3333 Work
111-222-3334 Home
111-222-3335 Other
111-222-3336 YYYYYY

While in TB they show like this:

111-222-3333 Work
111-222-3334 Home
111-222-3335
111-222-3336

Which makes it appear in TB as if the last two numbers do not have a "label" or "type" or whatever it is. It would be much better if they also showed as Other and YYYYYY. Otherwise a person might assign a "label" or "type" or whatever it is to that number and wipe out the correct value in Google.

Bill

You need to log in before you can comment on or make changes to this bug.