My ": Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.7) Gecko/20100104 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18 SuckFirefox/2.0.0.20 SeaMonkey/2.0.2" Does not recognize a modification of a PDF document that I want to send as email. Steps to reproduce: 1. Open and save (as test.txt") new text document with EditPad Lite or similar 2. type "ggg" 3. Print using PDFCreator (I believe any other Print to PDF application will also be capable to print as PDF document) 4. Click "Send as email", Save and proceed Seamonkey Create Mail Window will be opened 5. double click attached PDF document and check contents expected "ggg" actual: as expected 5a. Close e-mail 6. Switch to text editor and modify contents "ggg" to "GGG" 7. Redo Step 4., 5. expected: New modified contents "GGG" actual: Old contents "ggg" Additional observations: That also happens with any PDF documents that will be sent from WIN Explorer as E-Mail with small modifications. Same effect with OpenOffice.org function "Send document as ODF", currently this is a big problem fer me, because I can not be sure that corrections I did before I made a second attempt to send a document really will be integrated. I checked the cached document in <C:\Dokumente und Einstellungen\UserName\Lokale Einstellungen\Temp\moz_mapi\> Modification in Step 6 will not be visible there. Big modifications (deletion of a whole paragraph) always enforce creation of a "really" new attachment. This problem is not 100% reproducible. During creation of this bug report I did app. 5 tests, always with buggy result, but now suddenly I am no longer able to reproduce this problem. That matches with my normal experience, Sometimes a whole day everything works correctly for a whole day, and the next day I always have to restart Seamonkey to be sure that the correct version will be sent.

I was not able to reproduce that bug with .txt documents, only with PDF. But reason might be that the problem is not 100% reproducible, I only did 3 tests with .txt, but app 100 iwth .PDF (during my everyday's work)

It seems that this problem has vanished for me with SM 2.0.3. I will still watch that for 10 days, and if the problem will not reappear, I will close this bug.

Unfortunately I had to learn that the problem is not solved. Today I first sent a document "Test.PDF" created as a printout from PdfCreator with filled form fields (as a test to my own email address). Then I sent a PDF created from the OOo source document with the same name "Test.PDF" as the first document, but, of course, with no contents in the form fields. Expected: when I open "Test.PDF" in my mail, I see the export from the source document unfilled form fields Actual: I see the PdfCreator document with filled form fields, not working links and all other characteristics of such a print-PDF

Same problem as bug 356808?

Indeed, I am pretty sure that Bug 356808 is concerning the same problem.