Bug 66234

Summary: FILEOPEN: Cell Values in Wrong Order Opening DOC file with record-changes
Product: LibreOffice Reporter: Kevin Suo <suokunlong>
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: RESOLVED WORKSFORME    
Severity: critical    
Priority: high    
Version: 4.1.0.1 rc   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard: BSA
Crash report or crash signature: Regression By:
Attachments: The new doc file created, the doc file after revise in record-changes mode, and the screenshots before and after.

Description Kevin Suo 2013-06-27 05:01:24 UTC
Created attachment 81521 [details]
The new doc file created, the doc file after revise in record-changes mode, and the screenshots before and after.

Problem description: 
when opening a doc file with record-changes in a table, the cells values in the table are in a mass.

Steps to reproduce:
1. Create a new doc file with libreoffice, insert a 3x3 table, with some text in each cell,save;
2. Re-open that file, change into record-changes mode (edit->changes->record), change the value of a cell in the first row to something else, and save as another doc;
3. Re-open the revised doc file.

Current behavior:
Cell values after the revised cell break into the next row.

Expected behavior:
Cell values should be in the same cell as before the file was revised.

See the attachments for details.
              
Operating System: Ubuntu
Version: 4.1.0.1 rc
Comment 1 Kevin Suo 2013-06-27 05:09:59 UTC
It does not happen in ODT file and DOCX format, only in doc.

The resived doc file is OK (cell values appear in normal order) in other office applications like Kingsoft Office and Yozo Office, so I guess it's rather a FILEOPEN filter issue.
Comment 2 Kevin Suo 2013-06-27 05:17:42 UTC
This issue also appear in Libreoffice 4.0.4.2.
Comment 3 Kevin Suo 2013-09-04 09:50:25 UTC
Not reproduceable in LibreOffice 4.1.1.2 and 4.0.5.2, assuming fixed.
Comment 4 retired 2013-09-05 10:38:34 UTC
Hi Suokunlong, 

thanks for testing and keeping this up-to-date. Great you adjusted the state accordingly. If we don't have any specific commit that fixes this problem, the correct state is WORKSFORME (just for further action).

So adjusting state. Glad this is now working for you.
Comment 5 Kevin Suo 2013-09-06 01:41:00 UTC
(In reply to comment #4)
> Hi Suokunlong, 
> 
> thanks for testing and keeping this up-to-date. Great you adjusted the state
> accordingly. If we don't have any specific commit that fixes this problem,
> the correct state is WORKSFORME (just for further action).
> 
> So adjusting state. Glad this is now working for you.

Got it and Thanks for reminding!