User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:126.96.36.199) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729) Build Identifier: Thunderbird/3.0.4 & Firefox 3.6.3 The drag handler in Thunderbird is somewhat broken as apps with components that interface with IShellFolder work fine with Outlook, Live Mail, etc. but don't work with Thunderbird when using Windows Vista. The failure is when there is a drop and IShellFolder.Drop is called when dropping a Thunderbird email or attachment on it. Any attachment file or email dropped using Vistafails, but using XP or Windows 7, it all works fine. As an example download the examples at http://www.jam-software.com/shellbrowser_delphi/Samples.zip and run the JamExplorer.exe, it works fine for dragging Thunderbird emails and attachments using XP & Windows 7 but will not work for Vista (it interfaces with IShellFolder). Reproducible: Always Steps to Reproduce: 1. Run the JamExplorer.exe app or any other app that accepts drag & drop using the IShellFolder 2. Drag and drop an email or an attachment onto it (using Windows Vista only) and nothing happens. The action fails on the IShellFolder.Drop 3. Actual Results: Nothing happens Expected Results: Email or attachment should appear in the folder as it does when using XP or Win 7. Only occurs using Vista. Just did a test using Firefox and the same bug is there, you can drop onto Windows Explorer but not onto another software company's shell view.
Use this app running on Windows Vista and try to drag and drop an email or email attachment from Thunderbird onto it. Also try to drag and drop an image from Firefox as well. Run the same app again in Windows XP or Windows 7, do the same and this time it will work. Only happens with Firefox and Thunderbird.
Not sure if this is the correct bug since this is a sporadic issue. When dragging and dropping to desktop or folder on windows vista, sometimes the attachment is 0kb. But only sometimes. Below are the details from the source of one of the emails. I'm including it b/c of the multiple duplicate boundry openings that myfax has in there, it looks like it could be a potential source of the problem. B/c it's client info i've scrubbed the majority of the content of the emails. Return-path: <NoReply@MyFax.com> Envelope-to: xxxxxx Delivery-date: Tue, 25 May 2010 14:37:48 -0400 Received: from mail4-gur.protusfax.com ([188.8.131.52]) by host3.green-light.ca with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <NoReply@MyFax.com>) id 1OGz0e-000JuG-Hl for xxxxxxxxx; Tue, 25 May 2010 14:37:48 -0400 Received: from [10.99.2.121] (HELO ICE-06-GUR) by mail4-gur.protusfax.com (CommuniGate Pro SMTP 5.2.16) with SMTP id 2535858 for xxxxxxxxxx; Tue, 25 May 2010 14:37:57 -0400 To: xxxxxxxxx Subject: MyFax Delivery from 4165399223 MIME-Version: 1.0 X-Mailer: Mabry From: MyFax <NoReply@MyFax.com> Content-Type: multipart/mixed; boundary="49454480409_boundary" Message-ID: <201052552670_MabryMail_1212212669@protus.com> Date: Tue, 25 May 2010 14:37:57 -0400 --49454480409_boundary Content-Type: multipart/alternative; boundary="85161280632_boundary" --85161280632_boundary Content-Type: text/plain Content-Transfer-Encoding: 7bit --85161280632_boundary Content-Type: multipart/related; boundary="19441026449_boundary" --19441026449_boundary Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c/dtd html 4.0 transitional//en"> <html> <head> <title>SP5-0-F2EDelivery</title> </head> --19441026449_boundary Content-Type: image/gif Content-Disposition: inline;filename="272941049c.gif" Content-ID: <part1.382C4D3A.BCAF0B63@protusfax.com> Content-Transfer-Encoding: base64 R0lGODdhwAY3BIAAAP///wAAACwAAAAAwAY3BAAC/4SPqcvtD6OctNqLs968+w+G4kiW5omm6sq2 7gvH8kzX9o3n+s73/g8MCofEovGITCqXzKbzCY1Kp9Sq9YrNarfcrvcLDovH5LL5jE6re4FZW/pe y+f0uv2Oz+v3/L7fEBAYhyA4SOhQ+JY4YQi4uJBYWNEIEIn4iBhhOZkQKdgp6fh54Dm6scmA+kGZ ... ... ... JLNMM89EM00112SzTTffhDNOOeeks04778QzTz335LNPP/8ENFBBByW0UEMPRTRRRRdltFFHH4U0 UkknpbRSSy/FNFNNN+W0U08/BTVUUUcltVRTT0U1VVVXZbVVV1+FNVZZZ6W1VltvxTVXCV135bVX X90qAAA7 --19441026449_boundary-- --85161280632_boundary-- --49454480409_boundary Content-Type: application/pdf Content-Disposition: attachment;filename="4165399223_100525_272941049.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINMSAwIG9iag08PA0vQ3JlYXRvciAoKG51bGwpKQ0vQ3JlYXRpb25EYXRlIChUdWVz ZGF5LCBNYXkgMjUsIDIwMTApDS9BdXRob3IgKChudWxsKSkNL1Byb2R1Y2VyICgobnVsbCkpDS9U ... ... ... MSAwMDAwMCBuIA0wMDAwMDMwMzczIDAwMDAwIG4gDTAwMDAwMzA0MDYgMDAwMDAgbiANMDAwMDA2 MzIxNiAwMDAwMCBuIA0wMDAwMDYzMjM4IDAwMDAwIG4gDTAwMDAwNjMyNjYgMDAwMDAgbiANMDAw MDA2MzQxOCAwMDAwMCBuIA0wMDAwMDYzNTAwIDAwMDAwIG4gDTAwMDAwNjM1MzMgMDAwMDAgbiAN MDAwMDA5NzAxMCAwMDAwMCBuIA0wMDAwMDk3MDMyIDAwMDAwIG4gDXRyYWlsZXINPDwNL1NpemUg MjINL1Jvb3QgMiAwIFINL0luZm8gMSAwIFINPj4Nc3RhcnR4cmVmDTk3MDYwDSUlRU9GDQ== --49454480409_boundary--
(In reply to comment #2) > Not sure if this is the correct bug since this is a sporadic issue. When > dragging and dropping to desktop or folder on windows vista, sometimes the > attachment is 0kb. But only sometimes. Below are the details from the source of > one of the emails. I'm including it b/c of the multiple duplicate boundry > openings that myfax has in there, it looks like it could be a potential source > of the problem. B/c it's client info i've scrubbed the majority of the content > of the emails. It is not sporadic as the failure dropping to an IShellFolder interfaced object using Windows Vista happens 100% of the time. I have not encountered the 0 byte size yet, but this could be due to a large email and tempramental Vista as Thunderbird leaves the file existant for only 500ms which sometimes might not be enough time for Vista to prepare itself and do a Move (you see that annoying dialog saying calculating time to move when moving files in Vista). Justin
Product: Thunderbird → Core
QA Contact: general → general
You need to log in before you can comment on or make changes to this bug.