545205 - Modification in PDF document to be sent as email in a a second attempt not recognized

Status: RESOLVED DUPLICATE of bug 356808

(SeaMonkey :: MailNews: General, defect)

Description

[Rainer Bielefeld]

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.

Comment 1

[Rainer Bielefeld]

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)

Comment 2

[Rainer Bielefeld]

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.

Comment 3

[Rainer Bielefeld]

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

Comment 4

[WADA:World Anti-bad-Duping Agency]

Same problem as bug 356808?

Comment 5

[Rainer Bielefeld]

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