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)
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?
Reporter | ||
Comment 2•17 years ago
|
||
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.
Comment 4•17 years ago
|
||
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
Comment 5•17 years ago
|
||
I see this problem in a version of 2.0.0.6 with this patch but *not* in trunk (8/14).
Reporter | ||
Comment 6•17 years ago
|
||
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.
Comment 7•17 years ago
|
||
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
Reporter | ||
Comment 8•17 years ago
|
||
Agreed! Works as advertised on the trunk.
Comment 9•17 years ago
|
||
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
Updated•17 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•