Closed Bug 394901 Opened 12 years ago Closed 11 years ago

Mac implementation of nsIUserInfo does not handle non-ASCII

Categories

(Toolkit :: Startup and Profile System, defect)

All
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: hwaara, Assigned: hwaara)

References

Details

(Keywords: dogfood)

Attachments

(4 files, 1 obsolete file)

Attached image Bad name guess
Just tried out the Penelope beta, on OS X 10.4.10, Intel Macbook.

When I created a new account, it couldn't get my name right. It became "Hkan" instead of "Håkan". See screenshot.
Could you please provide some details? I have no trouble creating an account with the name 'Håkan'. Tested on Mac OS X.
Severity: normal → trivial
Hardware: PC → Macintosh
Penelope is "guessing" my name from my system preferences, and it didn't prefill it right. Of course I can correct this, and the account will be named correctly, but it's the "fetching the name from the system prefs" part it can't get right. Is that better?
Ahh, NOW I'm tracking. Thanks.
Priority: -- → P4
Target Milestone: --- → Future
This is a problem in Thunderbird as well. The first time I start it up (with no profile), the account manager manages to mess up my name like this.
Assignee: mozilla-bugs → nobody
Component: General → MailNews: Backend
Product: Penelope → Core
QA Contact: general → backend
Summary: Penelope can't guess my name right → Name "guess" in account manager is broken for non-ASCII
Håkan: if you're interested in debugging/fixing this, I think the code is around here: <http://lxr.mozilla.org/seamonkey/source/toolkit/components/startup/src/nsUserInfoMac.cpp#56>
Duplicate of this bug: 333232
Product: Core → MailNews Core
Duplicate of this bug: 318431
So turns out nsIUserInfoMac really cannot handle any non-ASCII cases of this. 

I'm gonna get rid of the ancient InternetConfig dependency and convert it to something that works a la year 2008.
Assignee: nobody → hwaara
Severity: trivial → normal
Component: Backend → Startup and Profile System
Keywords: dogfood
Priority: P4 → --
Product: MailNews Core → Toolkit
Summary: Name "guess" in account manager is broken for non-ASCII → Mac implementation of nsIUserInfo does not handle non-ASCII
Target Milestone: Future → ---
Attached patch Fix v1 (obsolete) — Splinter Review
Vlad, please ping me if there's a better mac toolkit reviewer for this.

This patch fixes the mac impl of nsIUserInfo to use modern Cocoa and system AddressBook APIs to get the info it needs: For example the user's full name, username, email address, etc.

I've made toolkit/components link to the AddressBook framework which is needed for this. This framework is available to all OS X users from 10.2 and ahead.

It should be pretty straighforward.

I wrote a xpcshell test locally to test that this works for non-ASCII names etc (which was the original bug), but I don't see a simple way to get automated testcases for this, since it depends on the user on the machine it is running.

With this patch, the account manager in Thunderbird gets my name right (yay!) and also it can now prefill the email address from my system addressbook which didn't work before.
Attachment #333164 - Flags: review?(vladimir)
Just a screenshot of it working. Compare to the first two screenshots.
Comment on attachment 333164 [details] [diff] [review]
Fix v1

Looks fine to me
Attachment #333164 - Flags: review?(vladimir) → review+
Got it in a minute before the freeze as 55c678462f90 with 1d8defa0efba as merge commit.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Backed out because it caused build failures e.g. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1219221082.1219221424.23160.gz

It compiled fine on all Thunderbird tinderboxes, and about half of the ones on the Firefox tree. 

I'm not 100% sure of this toolkit build stuff.

Is the problem that linking to AddressBook.framework (which toolkit now will require on OS X) is not sufficient to do only in toolkit/components/build but I also need to do it in toolkit/library? Ted?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Another thing I could do, would be to add -framework AddressBook to TK_LIBS (whatever the best way is to do that) because that's where other frameworks are defined. Would that make more sense?
Adding it to TK_LIBS certainly seems to be the precedent:
http://mxr.mozilla.org/mozilla-central/source/configure.in#4779

It makes sense if you're adding that framework as a requirement for the platform.
Flags: wanted-thunderbird3+
Ok, so here's the better approach for adding the AddressBook framework. Note that it's available on all macs since 10.2, so it's not a requirement anyone will notice.

Ted, can you just sign off on the configure.in change?

I've pushed it to the try server, but I'm not sure it builds with libxul on. I hope I can avoid to pull & build a whole new repo just for that... but I'm pretty sure this will fix the previous bustage.
Attachment #333164 - Attachment is obsolete: true
Attachment #334702 - Flags: review?(ted.mielczarek)
Comment on attachment 334702 [details] [diff] [review]
Patch, now with better compiling!

r=me on the configure.in part. The try server builds with libxul, AFAIK, since that's the default configuration.
Attachment #334702 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 334702 [details] [diff] [review]
Patch, now with better compiling!

r=me on the configure.in part. The try server builds with libxul, AFAIK, since that's the default configuration.
Pushed to mozilla-central as 9ad2f77e6778
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.9.1a2
Duplicate of this bug: 39299
You need to log in before you can comment on or make changes to this bug.