not reproducible in Win7 64bit with LibO 4.1.4.2

please try attaching an .odt with comments and the same file saved in .docx

edited summary notes.

Created attachment 91441 [details]
Example of docx file that will not save last comment.

Further testing shows problem only arises for file originally created by someone else (in this case a student), presumably on a Windows machine.  When I try to add comments to this file on my Linux machine, the text of the last comment is lost.  If  I create a file from scratch on my own machine, no problems.

Created attachment 91442 [details]
odt version of problem file that shows correct output

Student's file saved on my machine as odt document.  It shows correct output of comments.  Problems also found on other students' files, so not limited to one system.

(In reply to comment #2)
> Created attachment 91441 [details]
> Example of docx file that will not save last comment.
> 
> Further testing shows problem only arises for file originally created by
> someone else (in this case a student), presumably on a Windows machine. 

is this person using LibO 4.1.4.2 or another LibO release or MS Word?(In reply to comment #2)

> When I try to add comments to this file on my Linux machine, the text of the
> last comment is lost.  If  I create a file from scratch on my own machine,
> no problems.

these observations makes me think that the root of the bug is in the source .docx file.

Created attachment 91445 [details]
test .docx with comments created in Win7

try my file. it's a .docx with dummy text and 2 comments inside it.
it was created with LibO 4.1.4.2 under Win7 64bit.

can you add comments in your Linux machine? do you still experience issue?

OK.  I think I've narrowed it down.  Different sources of files were a coincidence.  I think this replicates the behaviour for any docx file.
1. Create a file and save it as a docx file using any software.  If using LO and file includes comments, they will work correctly.
2. Close file and then re-open it in LO.
3. Insert comments.  When you write the last comment, without moving the cursor from the comment, click save button. (This is how you would interact when commenting someone else's document).
4.  The save button will grey out and disable, but in fact the last comment is not saved.  You can close the file (without getting any warning about saving) and re-open it and the last comment will be blank.
If in step 3, you move the cursor to the body of the document or to another comment before clicking save, the last comment will be saved correctly.  "ENTER-ing" comments seems to depend on shifting the focus to another text area, which may not happen naturally for the last comment.
The behaviour above is different from LO saving odt docs and MSWord saving docx files with comments added.

Confirm error behaviour described occurs with your attachment 91445 [details].

> OK.  I think I've narrowed it down.  Different sources of files were a
> coincidence.  I think this replicates the behaviour for any docx file.
> ....
> "ENTER-ing" comments seems to depend on shifting the focus to another text
> area, which may not happen naturally for the last comment.
> ...


great!!! now I'm able to reproduce your bug on Windows!!! 
the key is to save without moving the cursor outside the comment window.

set status to NEW and platform to ALL.

reproduced issue with older releases up to 3.5.0 (tested with 3.4.3 too but it looses all comments after saving and reloading) with issue still present in 4.2.0.1rc

the bug is specific to .docx format and does not affect .odt and .doc

edited summary notes, changed version field and added Writer expert to CC list.

still reproducible with 4.2.5.2 and 4.4.0.0.alpha0+
Build ID: b9dca968c6fd0ab5ca140c65b0e54d153cd34986
TinderBox: Win-x86@42, Branch:master, Time: 2014-07-18_22:51:20

I think I am experiencing this bug (lost a whole bunch of grading this week as a result!).  I have LO 4.3.3.2 from Arch Linux repos; some macro customization which I am reluctant to lose so haven't tried purging my install yet.  Please let me know if there's some work I can do to help debug.

I am finding that the content of comments created with a macro are also not being saved to docx.  So it is not dependent just on the final state of the document -- it seems to have to do with whether the comment was ever manually exited.  

Here's the macro I'm using:  

sub createCommentwithCheckmark
    rem create the annotation object
	oAnno = ThisComponent.createInstance("com.sun.star.text.textfield.Annotation")
	rem Chr 10004 is the decimal for hex code 2714, "heavy checkmark"
	oAnno.Content = Chr(10004)
	oAnno.Author = "Matt Price"
	oText = ThisComponent.Text
	rem check to see if anything is selected
	oSels = ThisComponent.getCurrentSelection()

	If Not IsNull(oSels) Then 
	oVC = ThisComponent.CurrentController.ViewCursor
		oText.insertTextContent(oVC, oAnno, True)

	Else 
		oVC = ThisComponent.CurrentController.ViewCursor
		oText.insertTextContent(oVC.Start, oAnno, False)
	End If
end sub

I'm guessing that using "insertTextContent" is the only line that really matters here

Created attachment 109769 [details]
.odt demonstrating correct function

.odt file saves attachments properly, even if cursor remains in final annotation, and even though first annotation was input via macro with no manual intervention.

Created attachment 109770 [details]
.docx shows auto-inserted annotation doesn't show up.

Shows auto-inserted annotation is not saved to .docx, despite being saved to .odt.

Since this bug appears to persist in recent builds would it be permissible to change the version to 4.3.2 or similar?

no, this is not how the version field should be edited.

try to change it to a later version and you will see this message:

"You are changing the version of the bug to a later version. As the version field of the bug should show the earliest version manifesting the bug, please reconsider, if you really want to do this. Please do not change a version, because it also manifests in a later version. for details, please see the guidelines"

thanks for the clarification, Tommy.