MozillaZine

[Ext] AttachmentCount 2.3 [2016-06-30]

Announce and Discuss the Latest Theme and Extension Releases.
alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted May 9th, 2011, 12:24 pm

AttachmentCount for Thunderbird has been released.

AttachmentCount adds a custom Attachment Count column to the thread pane showing the number of attachments in a message.

Features:
  • If there is only 1 attachment, an icon will be shown for its content type or file extension.
  • If all attachments are deleted or detached, an appropriate icon will be shown.
  • The pref alwaysShowCount may be changed to show the number rather than an icon.
  • Experimental plain text attachment preview.
Comments welcome.
Last edited by alta88 on July 12th, 2016, 9:26 am, edited 3 times in total.

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted August 24th, 2011, 5:46 pm

AttachmentCount v1.3 has been released.

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted August 24th, 2011, 6:57 pm

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 ?.

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted August 24th, 2011, 7:25 pm

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.

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted August 24th, 2011, 11:32 pm

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

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted August 25th, 2011, 6:08 am

mad.engineer wrote:the issues that I've listed above are fixed in TB 7/8, hence AttachmentCount will work correctly with the newer TB versions.

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted September 20th, 2011, 6:50 pm

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

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted September 21st, 2011, 6:22 am

TB8 works for me, haven't tested on Tb7.

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted September 21st, 2011, 10:35 am

I tried it again with EarlyBird [8.0a2] today [IMAP]. Same result that the count is incorrect. You can see in this screen shot: http://img17.imageshack.us/img17/5028/tb1c.png that the AttachmentCount show that there are "10" attachments in this message. But when I open this actual message, there is only one attachment: http://img833.imageshack.us/img833/7070/80591938.png in it ?

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.

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted September 22nd, 2011, 6:51 am

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.)

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted September 22nd, 2011, 6:06 pm

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

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted September 22nd, 2011, 10:50 pm

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.

Subject: XXXX
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_001B_01CC75EA.DDA29AC0"

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01CC75EA.DDA29AC0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

XXXX

------=_NextPart_000_001B_01CC75EA.DDA29AC0
Content-Type: application/pdf;
name="aaa.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="aaa.pdf"

XXXX

------=_NextPart_000_001B_01CC75EA.DDA29AC0--

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted September 23rd, 2011, 10:18 am

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


X-Files: XXX.jpg, image.png, XXX.jpg, image.png, image.png, image.png, image.png, image.png, image.png,XXX.pdf
Subject: XXX

Content-Type: multipart/mixed;
boundary="------------080001070202070905040806"

This is a multi-part message in MIME format.
--------------080001070202070905040806
Content-Type: multipart/alternative;
boundary="------------030704030106040005070808"


--------------030704030106040005070808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

--------------030704030106040005070808
Content-Type: multipart/related;
boundary="------------000406050608030207050005"


--------------000406050608030207050005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

--------------000406050608030207050005
Content-Type: image/jpeg; x-apple-mail-type=stationery;
name="XXX.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.03060100.01060906@XXX.com>
Content-Disposition: inline;
filename="XXX.jpg"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part2.05030601.04040803@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/jpeg; x-apple-mail-type=stationery;
name="XXX.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part3.08060906.08080609@XXX.com>
Content-Disposition: inline;
filename="XXX.jpg"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part7.00040904.03050909@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part8.01000700.05000206@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part9.03040608.05090607@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part10.09020103.09060006@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part11.07090809.03000208@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: image/png;
name="image.png"
Content-Transfer-Encoding: base64
Content-ID: <part12.09080002.07010203@XXX.com>
Content-Disposition: inline;
filename="image.png"

Content-Type: application/pdf;
name="XXX.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0="XXX.p";
filename*1="df"

alta88
 
Posts: 980
Joined: January 28th, 2006, 3:08 pm

Post Posted September 24th, 2011, 11:29 am

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.

mad.engineer
 
Posts: 314
Joined: August 8th, 2006, 4:08 pm

Post Posted September 24th, 2011, 1:56 pm

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

Return to Extension/Theme Releases


Who is online

Users browsing this forum: No registered users and 4 guests