vCards are handled strangely in Thunderbird. They're attachments, but we hide them in the attachment list (mostly so that they don't cause the paperclip to show up in the thread pane). However, paranoid users (with Simple HTML or Plain Text reading on) will see the vCard as a regular attachment, since vCards can contain HTML, I gather. We *also* handle the paperclip-hiding in msgHdrViewOverlay.js, and as far as I can tell, the Gloda "hide the paperclip" pass doesn't account for vCards. All of this is very silly. There are a few things we can do here: 1) Move the vCard-hiding into libmime. That should make the Gloda pass handle vCards properly, as well as simplifying our UI code (currently we have to be smart about "skipping" vCard attachments). 2) Make the vCard emitter more secure so that we can always show it inline, making the paperclip consistent. (Probably not worth the time.) 3) Kill the vCard emitter entirely and just treat them like normal attachments, with some bonus logic to make the thread pane hide the paperclip if the only attachment is a vCard. The logic could be pretty similar to how msgHdrViewOverlay.js is now. This would require us to associate .vcf files with Thunderbird so that we can import them when you double-click them in the reader. I'm leaning towards (3). I don't think vCards are sufficiently useful to show them inline, especially when people sometimes treat them like sigs. For one-time vCards, I think it's plenty to let people double-click them to import. The only downside is that it would be harder to quickly get the email address without importing, but if all you wanted was an email address, one would hope that the sender would just send you an email address. Thoughts?
The advantage of showing them in-line is that you can get all the address/phone number/web page information displayed without having to open or import them. If you could only double-click to import the vcard, then that would be pretty poor, as you'd have to then import and go find the card - when you might not even want to import the card in the first place.
Indeed there's no special treatment for vcards in the "hide the paperclip" gloda pass. Having that pass in Gloda is still important, since the paperclip icon in the thread pane might be erroneously present when we have what used to be a Part 1.2-like attachment in the message. I'm in favor of always showing the vcards inline, regardless of the display attachments inline pref, because: - no one ever wants to save them: there no such thing as saving a vcard to a .vcf file, - what you want to do is 1/ check the information at a glance, because you don't know who the person is and and 2/ add the information to the address book -- this can be achieved by clicking on the buddy icon when the vcard is displayed inline. That way, we wouldn't need to make Gloda smarter and we could remove the special logic in msgHdrViewOverlay.js. The only downside I can see is that 1/ some people might fight tooth and nails for keeping a way to hide vcards and 2/ if we want to do this right, we need to take into account the case where we're unable to parse the vcard and, therefore, still want to show it as an attachment. I feel like this is more or less what you had in mind for 2).
(In reply to Jonathan Protzenko [:protz] from comment #2) > - no one ever wants to save them: there no such thing as saving a vcard to a > .vcf file, There is such a thing as a .vcf file (see Tools -> Import -> Address Books), I think we can export from the AB to it, we just can't save directly from the email.
Oh right. What I meant is that I was having a hard time figuring out why someone would want to save a .vcf file, but I admit we should still offer the option. Maybe something in the inline card, like a "save" link? We could even take this as an opportunity to refresh the visual appearance of the inline vcard?
> why someone would want to save a .vcf file FYI, many phones (my DECT wireless fixed line phone, and many feature phones, and IIRC my Androids) can import .vcf files into the phonebook. As for 2): There is code to not show vcards online *if* the user enabled the "no HTML" prefs or the "don't show me strange uncommon content types", including particularly stuff like vcard and apple double. This code is just a few lines in mimei.cpp, it's inline with other code there, and must stay. As for the rest, I agree with anything you said.
Here's another option, which is a bit closer to the status quo: In msgHdrViewOverlay.js, always hide the paperclip in the thread pane if the only attachments are vCards. Do the same when Gloda indexes the message. Then, back in msgHdrViewOverlay.js, do one of the following: a) hide the vCard in the attachment list when it's shown inline (the status quo) b) always show the vCard in the attachment list (but still hide the paperclip in the thread pane) (b) would be nice because it'd be easier to save the vCard, in case you wanted to forward it or open it in another application.
I think we decided not to show the vcard in the attachment list because it was annoying, and we thought v-cards would be common. With the way the attachment pane works now, I think it would be even more annoying to have it in the attachment list because if there was an other attachment, you'd have to go through the grief of expanding the attachment widget to see the other attachment.
> (b) ... save the vCard, in case you wanted to forward it or open it in another application. Agreed. The lack of this option has dramatically limited the usefulness of vcards in emails. Instead of showing it in the attachments list, we could also offer an "open" button (small icon only, no text) inside the inline view. (offtopic: > if there [is more than 1] attachment, you'd have to go through the grief of expanding the > attachment widget to see the other attachment. Is there a bug about this? This annoys me to no end, because my fax->email gateway sends me 2 attachments.)
(In reply to Ben Bucksch (:BenB) from comment #8) > Is there a bug about this? This annoys me to no end, because my fax->email > gateway sends me 2 attachments.) That's bug 647036. Ask bwinton about it (I have no problem fixing it, but he's not convinced that it's useful). You can also install the add-on "Attachment Options" if you like.
You need to log in before you can comment on or make changes to this bug.