Good add-on. But I'm seeing inconsistent/wrong attachment count on some messages in my case. TB6, IMAP, W7. For example, one message has only one actual word file attached, but AttchmentCount show that it has 4 ?. Some people use Outlook with Rich Text format and use fancy html signatures, not sure if your add-on is counting them as real attachments, thus showing 4 instead of 1 ?.
yes, the results are only as good as the Tb api (which was poor). fortunately, protz fixed some issues and the current 1.3 is ready for the core fixes that will come in Tb7/8. there has also been core attachment work done so that inline parts won't be counted as attachments etc. AC looks good in earlybird.
OK, so does this mean, that the functionality provided by AttachmentCount will be added natively in TB7/8 OR the issues that I've listed above are fixed in TB 7/8, hence AttachmentCount will work correctly with the newer TB versions?. Thanks
Tried AttachmentCount v1.3 with TB 7.0b3 today. Still seeing the same inconsistent behavior with the count. Some messages, it shows correct count, others incorrect. Is this add-on suppose to work correctly with TB 7.0b3 (or final version), or we'll have to wait for TB 8/9?. Thanks
I also have the following in my user.js: user_pref("mail.imap.mime_parts_on_demand", false); user_pref("mail.imap.fetch_by_chunks", false); user_pref("mail.server.default.mime_parts_on_demand", false);
not sure if the above has anything to do with the count showing wrong results.
imap download prefs would impact the counts for imap, but should result in simply an indicator of attachments rather than a count (if not allowed to download the message, a count can't be made) so a large inaccurate count seems it would have something to do with the mime parts.
i would have to take a look at the message. you could save it as a .eml then edit it to remove any identifying bits, and mail it to me (gmail.com).
(also, just to be sure, you could try setting the prefs to true and see if the result is different.)
alta88, I use TB for my work related mail and unfortunately, due to that if I sanitize a message for your review, that would leave pretty much nothing as I'd have to clean up almost majority out of it. If you could instead let me know what specific info you're interested in, I could possibly see if I can get it for you. Thanks
you could remove almost everything except the content-type and boundaries, changing content to XXXX in the parts. below is a sample, containing a header and 2 parts delimited by boundaries given in the header, the email text and a pdf attachment.
Here's the info. BTW, turning off those options in Config Editor did not make any difference.
Looking at the mail headers, I have a suspicion as to why the count is showing up as "10" instead of "1" where there is only one real "pdf" file as the attachment (I'm no expert and could be wrong here, this is just a guess). If you see the X-Files header below, you'll notice that it show "10" files with "9" of them as "in-line" images in the email and only one real pdf file as the attachment. So, somehow the add-on is counting all these in-line images [as seen by "Content-Disposition: inline;" below] as attachments which are not necessarily real attachment files, but just in-line images (people using Rich Text/HTML clients to include fancy pics/signatures etc), hence the count show up as "10" instead of "1"?. Not sure if your add-on is just looking at the X-Files: header and counting the number of entries in it and showing them as the actual count?. May be the add-on should look at "Content-Disposition: inline;" and say since it is an inline image and not a real attachment, it should not be counted?. Note that TB only shows this one "pdf" file in the attachment window/section of the message itself. Would be interested to get your thoughts and if there is any way to fix it in your add-on. Thanks
This is a multi-part message in MIME format. --------------080001070202070905040806 Content-Type: multipart/alternative; boundary="------------030704030106040005070808"
you're quite correct in the assessment. the problem is that the api (separate from how attachments are handled in the pane for the selected visible message) doesn't return the content-disposition, and certain parts that are not strictly attachments in fact are. feed enclosures for one. so it's a question on which side to err..
i will have to test the new api fixes to see if former necessary relaxation of what an attachment is can be removed, so to both avoid false positives and include true negatives.
it's an old problem in that various mailers don't always strictly identify attachments and mime parsing gets difficult. core Tb devs are actually working on a new mime part parser and handling of parts that don't strictly adhere, and how users can/should see them etc etc.
I thought that the API fixes were included in EarlyBird per your earlier reply, or is it not true?. Please keep us posted if you find anything new on this front or if there's any way to workaround/correct it in the add-on. I personally think that this is a very useful add-on but till there's some kind of fix available, I'll just have to wait. Thanks
mozillaZine is an independent Mozilla community and advocacy site. We're not affiliated or endorsed by the Mozilla Corporation but we love them just the same.