User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031007 New VCard UI implemented in bug 14373 does not save info into the following fields: SCREEN NAME Any of the HOME ADDRESS fields Reproducible: Always Steps to Reproduce: 1. Goto Edit: Mail & Newsgroup Account Settings: Your Account: Edit VCard: 2. Go to the Addresses panel and fill in info for the HOME address 3. Click OK to save the info 4. Return to the Edit VCard .. Actual Results: The info for Home Address or for Screen Name are gone now Expected Results: Data should still be there ...

Confirmed in build 2003100705 on Mac OS X 10.2.8 The necessary fields are missing from nsAbCardProperty::ConvertToEscapedVCard. The only 'home' field in that function is the Home-phone, and that's indeed the only one that got saved.

Scott: I've asked for a vCard component to be created see http://bugzilla.mozilla.org/show_bug.cgi?id=221556 this way we could move all vCard bugs to this component.

-> All/All

With the current code isAPropertyOf always returns the first instance of the property and does not match against subproperties. This means it cannot cope with adr;work and adr;home in conjunction with a property that has multiple value fields. If a new function of isPropertiesOf that will check on subproperties as well as the property to return the correct match. Going with that there would have to be an addProps function that knows how to add a new multi-property object without trying to use an existing one.

an addressbook card in mozilla has some new fields which were not in the 4.x addressbook. the current vCard code in mozilla comes right from Netscape 4.x. this bug is sort of related to bug #30684, "RFE: Support for "custom" vCard values..." one thing we should look into is if the more recent vCard RFC (see bug #29106) specifies how we should be handling some of our new attributes. for all those that aren't specified, I think we'll have to do X-mozilla-foo trick.

We have several stages to go through: 1/ Full support of vcard 2.1 - http://www.imc.org/pdi/vcard-21.txt (sort of this bug) - things like home address details and nickname. 2/ Support of mozilla specific fields (again this bug) - things like screenname and more than one URL. 3/ Support of vcard 3.0 - RFC 2426 - http://www.faqs.org/rfcs/rfc2426.html (bug 29106) - of course including full backwards compatability. 4/ Support of custom fields not in the addressbook, that is not loosing them (bug 30684).

Some fields, like more than one email address and nickname should be supported once mozilla supports vCard 3.0 (bug 29106) so adding dependency.

Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b)Gecko/20031110 Reproducable: Always Adding a semicolon to fields in the vCard have the following consequences ("it" is referring to the semicolon): Title field: Replaces anything before semicolon with whatever is after it Department field: Erases whatever was written after it, and including itself Organization field: Replaces the Department field with whatever was written after it Address field 1: Places whatever was written after it in the City field, and pushes all other fields (up to the Web Page field) in front of it. Address field 2: See Address field 1 City field: Similar behavior as Address field, but moves whatever is after it to the next field and keeps pushing. State/Province field: Same behavior as City field Zip/Postal field: Same behavior as above Country: Removes whatever is written after it Did not check any other fields, but I guess semicolons are used as field separators or something.

Andree: Yes ; is a field delimiter in vcards and mozilla should probably deal with that better, but that should be a different bug not this one. If one has not already been logged, then please log one.

*** Bug 228482 has been marked as a duplicate of this bug. ***

Bug confirmed for Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6) Gecko/20040113

It would be cool if there would be a note when editing vcards or if the inputs are greyed out or somthing. I tried to insert my data again and again and wondered whether it was my fault....

I reckon it would be less work to simply fix the bug (instead of greying something out), since Jo seams to have found the cause. I don't feel competent to mark this bug 'assigned' since I wouldn't know /whom/ I should assign it, but I consider this bug quite disturbing, and therefore I'll try it if nothing happens within the next days... Btw, if Andree had found (or created) an issue meanwhile concerning the semicolon bug, it would be nice to drop a note here, wouldn't it?

Unfortunatly I'm not familiar with the moz-source and at the moment I'm not able to compile anything, because my notebook is at it's edge - but if there is any other way I can help, please feel free to contact me! ---- some time ---- Ok, I did a bit of research: I think this is a duplicate of 221991 as also 227873 is and some others are. If we take a good look at the rfc2426 and implenment it correctly, by escaping the semicolon and the newline charakter about three major vcard-bugs would be solved. Then the other filds have to be implemented, but I dont think that this isn't a too big deal, or is it??

Moritz: comment#6 explains how all these bugs sit in relation to each other - stage 1 is bug 221991.

Ok, sorry about that - anyway if there is anything I can help with...

Well if you're any good with C++ then I can point you in the right direction. http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsVCardObj.cpp#415 is one place to start looking and see comment#4 too.

Ok, I'm quite a newbe. I did a bit of C++ and VB (unfortunately). So I've got a few Ideas what might help but I'm not shure, especially because it there is almost no documentation. Next week I get my new computer, so if there is anybody who would take my by the Hand I'll do my very best. Or if you say, that it makes no sense for a newbe, I'll just let you do your job.

*** Bug 238153 has been marked as a duplicate of this bug. ***

two things to do: 1) change hideABPicker argument to be "editingVCard" or something like that. http://lxr.mozilla.org/mozilla/source/mailnews/addrbook/resources/content/abCardOverlay.js#118 2) key off "editingVCard" and hide all the UI elements (including screenname?) that don't map to values that we remember in our vCard 2.1+ format.

Initial take on a patch

Comment on attachment 148548 [details] [diff] [review] As suggested in comment 20 A system along the lines of the account manager could be useful here i.e. have a hidefor="vcard" attribute on all the elements that need to be hidden.

ian, thanks for starting this. but neil's idea for hidefor="vcard" system might work better. I'll have time this weekend to look it over and test it out.

Just been looking how it is done for Thunderbird and that checks for "escapedVCardStr" then calls HideNonVcardFields() which uses: document.getElementById('nickNameContainer').collapsed = true; etc Should we be consistent with that?

Implements hiding of fields not required the same way Thunderbird does, plus some whitespace cleanup.

ian, this fix looks good. I'm just testing it now for trunk and 1.7 and then I'll land i.t thanks for porting mscott's tbird fix back to seamonkey. I'll let mscott decide what he wants to do with the whitespace fixes. note, I looked at 4.x and we had a "nickname" field. but 4.x had the same bug where nickname was not persisted since it was not stored in the vCard 2.1+ format. I'm sure more recent version of the vCard format would allow for all these other fields, but that's a separate issue.

fixed on the trunk and 1.7. thanks again, ian.

verified with recent branch builds

*** Bug 245595 has been marked as a duplicate of this bug. ***