Closed Bug 391478 Opened 17 years ago Closed 17 years ago

Mac OS X Address Book Display Name is always Last Name First Name

Categories

(MailNews Core :: Address Book, defect)

1.8 Branch
All
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: jhsieh, Unassigned)

References

()

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: 2.0.0.6 (20070807) Using the build from mistermartin75 which includes the recently landed OS X Address Book code into 2.0.0.6, all works as expected except the Display Name. The code seems to indicate that Display Name is supposed to be generated based on what the OS X AddressBook specifies for name ordering (First Name Last Name or Last Name First Name). For some reason, no matter what my OS X Address Book specifies, Display Name is always generated as Last Name First Name. The PDF file at the URL shows the Address Book settings I think pretty well. Because Display Name is always Last First, when you are in the Compose window and try to match on an entry from the OS X Address Book, it always comes out as Last First <email> So an entry for John Smith - john.smith@someglorp.com always shows up in the compose window "To" field as Smith John <john.smith@someglorp.com>. Reproducible: Always Steps to Reproduce: 1. Enable OS X Address Book per instructions in 203927 2. Make sure OS X Address Book Preferences->General specifies Display Order for First Name Last Name 3. Open up Thunderbird Address Book and look at any card from the OS X Address Book. Contact Display Name always shows Last Name First Name. Actual Results: Display Name still displays Last First no matter what is done to try to influence that. Expected Results: Display Name should be generated based on OS X Address Book Preferences (and that appears to be the intent of the code) My system is OS X 10.4.10, Hardware is PowerBook G4 1.67Ghz (PPC).
Isn't this more like a general problem that the contacts sidebar in the compose window doesn't respect the "View" -> "Show Name As" setting from TB's address book?
No. That is not the issue. Display Name is generated based on the obtained First and Last Names. If you look at View->Show Name As, you have 3 options: First Last, Last First, and Display Name. Display Name is auto-generated. And this is what gets used in the composition window when you choose an entry out of the Address Book. The section of code in question is: + if (kABPersonFlags && (order == kABFirstNameFirst)) { displayName.Append(m_FirstName); displayName.Append(' '); displayName.Append(m_LastName); This says that if the entry in the OS X AddressBook is a Person (not a Company) and the entry says to display First Name First, then build a Display Name that is First Name Last Name. At least, that is what appears to be the goal. However, somewhere, this conditional is failing (and I don't have the MacOS programming knowledge to figure out what is not getting read correctly). That is what this bug is about - why Display Name does not get generated correctly based on settings in the OS X Address Book.
The Display Name is unimportant if TB repects the "Show Name As" setting everywhere.
James, can you run a test with a current trunk nightly build of Thunderbird 3.0? Please remember to create a test profile. Does is also happen with this version?
Component: Address Book → MailNews: Address Book
Product: Thunderbird → Core
QA Contact: address-book → addressbook
Hardware: Macintosh → All
I see this problem in a version of 2.0.0.6 with this patch but *not* in trunk (8/14).
When I was first testing the feature, I couldn't get the trunk nightly to run. Last night's build seems to work fine. Build version 3.0a1pre (2007081403) does not appear to display this problem and DisplayName honors the OS X Address Book settings as expected from looking at the code.
Due to we don't officially support this feature on 1.8 branch this bug should be WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Version: unspecified → 1.8 Branch
Agreed! Works as advertised on the trunk.
Mmm, no, a bug in someone's unofficial build is INVALID; WONTFIX is a bug in official builds for which the module owner has decided he won't accept a fix.
Resolution: WONTFIX → INVALID
Status: RESOLVED → VERIFIED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.