Download it now!
Bug 103938 - FILESAVE: Writer loses saved column widths
Summary: FILESAVE: Writer loses saved column widths
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.4.3 release
Hardware: x86-64 (AMD64) All
: high normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.4.0 target:5.3.0.1 target:5.2.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-11-15 13:58 UTC by tony
Modified: 2016-12-20 05:16 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of deformed column widths after saving and re-opening. (33.72 KB, application/pdf)
2016-11-15 15:11 UTC, tony
Details
odt file showing example table (9.67 KB, application/vnd.oasis.opendocument.text)
2016-11-15 15:49 UTC, tony
Details
Step-by-step reproducibility instructions and screenshots (508.10 KB, application/vnd.oasis.opendocument.text)
2016-11-23 14:49 UTC, tony
Details
As above in pdf format (495.46 KB, application/pdf)
2016-11-23 14:57 UTC, tony
Details
sample .fodt document table with 3 columns -- loses one on opening (26.90 KB, application/vnd.oasis.opendocument.text)
2016-11-23 15:33 UTC, V Stuart Foote
Details
same sample .odt archive document with 3 columns -- loses one on opening (8.58 KB, application/vnd.oasis.opendocument.text)
2016-11-23 15:42 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tony 2016-11-15 13:58:18 UTC
Column widths of table are set, document is then saved but on re-opening the document, the table's column widths are (very) wrong.

Reproducible? Yes. Happens many times.

Happened in previous versions? Yes.
Comment 1 Xisco Faulí 2016-11-15 14:46:29 UTC Comment hidden (obsolete)
Comment 2 V Stuart Foote 2016-11-15 14:49:26 UTC
As noted ideally provide a test document that demonstrates the issue with Table columns.

Please understand that the 5.1.6 build is EOL for the 5.1 branch (i.e. nothing will be changed). 

Best if you can install current 5.2.3 release and retest.

If still an issue, please provide full Steps to Reproduce, including the format you are saving the document as (ODF or OOXML) and the test document.
Comment 3 tony 2016-11-15 15:11:34 UTC
Created attachment 128763 [details]
Example of deformed column widths after saving and re-opening.

I do not seem to be able to submit a LibreOffice odt document to show you so I have attached a pdf of the same document.
Comment 4 tony 2016-11-15 15:45:58 UTC
I have just done a clean install of LibreOffice_5.2.3.3_Linux_x86-64 and the same problem exists.
Comment 5 tony 2016-11-15 15:49:40 UTC
Created attachment 128766 [details]
odt file showing example table

Another attempt to save an odt file showing the problem.
Comment 6 MM 2016-11-15 22:18:00 UTC
I see the column width error. But when going to 'table properties' > 'line arrangement' and set the right most arrows in 'user defined', save and reload, the table width stays the same.
If I insert a table myself, save and reload, the column border doesn't get removed.
So how can we reproduce this one from scratch ?
Comment 7 tony 2016-11-16 13:23:17 UTC
Sorry, MM, I can't find the menu item to which you refer. On my version of Writer (Version: 5.2.3.3, Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf) the menu tree looks like this:-
Table > Properties...

Clicking on 'Properties...' opens a dialog entitled 'Table Format', which has the following tabs:-
Table, Text flow, Columns, Borders and Background.

There is no mention of 'line arrangement' in any of those tabs and therefore there is no facility to "set the right most arrows in 'user defined'".

Right-clicking in the table and then clicking on 'Table properties...' produces the dialog box just described above.

As stated before, this column distortion error only ever happens on a newly-created document that is saved for the first time, closed and then re-opened for the first time. Once the document has been saved two or more times, the table columns settings stay as they were saved.
Comment 8 MM 2016-11-16 17:18:48 UTC
Check with 5.1.6.2 and 5.2.3.2 under ubuntu 16.04 x64 and 5.1.6.2 under windows 7 x64.

Line arrangement is in the borders tab. When you switch 'on' the right most arrows (set outer border and all inner lines), save and reload, these stay on.

Also tried it with a new file, made a table, saved. But, all borders stay on.
Comment 9 tony 2016-11-17 14:31:14 UTC
MM, yes thanks, I found line arrangement where you said it was. The reason for my confusion is that my post did not refer to borders at all. My problem is with the column widths initially set by me being lost on first saving the file and then re-opening it (please see my original and subsequent posts). 

Losing borders is a trivial problem for me compared with having my carefully saved column widths wrecked and, in some cases, having the last column (and all the data in it) disappear completely.
Comment 10 A (Andy) 2016-11-19 08:32:34 UTC
For me not reproducible with LO 5.2.3.3 (Win 8.1).
Comment 11 tommy27 2016-11-23 05:24:40 UTC
no repro too under Win8.1 x64 using LibO 5.2.3.3
must be Linux specific
Comment 12 tony 2016-11-23 14:49:41 UTC
Created attachment 128959 [details]
Step-by-step reproducibility instructions and screenshots
Comment 13 tony 2016-11-23 14:57:43 UTC
Created attachment 128960 [details]
As above in pdf format

The problem can be reproduced using Windows 10 Pro and LibreOffice 5.2.3.3 and reproduction instructions are shown in the attached document.
Comment 14 V Stuart Foote 2016-11-23 15:33:16 UTC
Created attachment 128964 [details]
sample .fodt document table with 3 columns -- loses one on opening
Comment 15 V Stuart Foote 2016-11-23 15:42:46 UTC
Created attachment 128965 [details]
same sample .odt archive document with 3 columns -- loses one on opening

Confirming loss of display of third column on reopening document.

The .fodt and .odt archive include the column in ODF as style-name Table1.C1 & Table1.C2--but they do not render to document canvas.
Comment 16 V Stuart Foote 2016-11-23 16:00:42 UTC
Confirmed on Windows 10 Pro 64-bit (1607) en-US with
Version: 5.2.3.3 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US); Calc: group

and current master
Version: 5.3.0.0.alpha1+
Build ID: 0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-19_23:33:29
Locale: en-US (en_US); Calc: CL
Comment 17 V Stuart Foote 2016-11-23 16:24:47 UTC
This is a regression between 4.3.6.2 and 4.4.6.3 releases, needs to be bibisected.

Here are STR

1. Open Writer
2. enter two rows of text, separated by tabs

Column1 <tab> Column2 <tab> Column 3 <return>
25% width <tab> 35% width <tab> 40% width <return>

3. select that text
4. Table -> Convert -> Text to table
5. uncheck "equal width for all columns" if set
6. Table -> Select -> Table
7. Table -> Properties (Table Properties on older builds)
8. On Table Properties dialog -- note table width 6.93" (en-US Letter)
8a. Table tab: set Left radio button
8b. Columns tab: set width of columns 1.73", 2.42", 2.77"
9. save to ODF (.odt or .fodt)
10. while open the canvas shows all three columns
11. close
12. reopen -- 3rd column is missing, and 1st and 2nd column are stretched.
Comment 18 V Stuart Foote 2016-11-23 16:36:12 UTC
Regression as of
Version: 4.4.4.3
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
Locale: en_US
Comment 20 Terrence Enger 2016-12-07 16:55:05 UTC
Working on debian-stretch in the 50max bibisect repository, following
the steps in comment 17, I see that the was introduced somewhere in
the 8 commits ...

          commit    s-h       date
          --------  --------  -------------------
    good  8d7a017c  853c2fc7  2015-01-23 13:04:25
    bad   a7d852ff  ad50b9a8  2015-01-23 16:13:24

In detail, (lines rewrapped) ...

    terry@lynn-stretch:~/lo_hacking/bibisect/bibisect-50max$ git bisect skip
    There are only 'skip'ped commits left to test.
    The first bad commit could be any of:
    5fd8a74fb9ca7ad070433ce3510918802a3bcce1
    13704dc1c4aab2374a5fbfd5de45eba0eb7b128d
    c8f58541eeed5737b27b22855eed8cf67d44541a
    0dac36ca2a71aec3224f3b195e055e799b734227
    5e6c7fb196611594938560da2befcdd862fb3fd4
    4bbc37c608b7517dba9e5665f1b4dbb1fec96157
    5f26656bc6c2bcbd233071041729d9a5ff677f34
    a7d852ffb3609abddf82ba874ede763f7222e9b5
    We cannot bisect more!
    terry@lynn-stretch:~/lo_hacking/bibisect/bibisect-50max$ git bisect log
    # bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e]
        source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
    # good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091]
        source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
    git bisect start 'latest' 'oldest'
    # bad: [0c30a2c797b249d0cd804cb71554946e2276b557]
        source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
    git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557
    # good: [770ff0d1a74d2450c2decb349b62c5087e12c46b]
        source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03
    git bisect good 770ff0d1a74d2450c2decb349b62c5087e12c46b
    # bad: [259e888083cf7697956bb7e5f2691e8153eadb4c]
        source-hash-1884c0bbd40f0ded41d7a1656cb64fb1f6368c36
    git bisect bad 259e888083cf7697956bb7e5f2691e8153eadb4c
    # good: [ee7c82541a2e99f76af570d3faa897504149913a]
        source-hash-54defd1bd3359c95e45891c7294847d0cebca753
    git bisect good ee7c82541a2e99f76af570d3faa897504149913a
    # bad: [504f60cf9ee84da75d4c15a62dedb18976129c14]
        source-hash-c8af68bc5adf093f9df803f6fe0147ac9d116169
    git bisect bad 504f60cf9ee84da75d4c15a62dedb18976129c14
    # good: [00c3cacafec11fdfbdf7f0c8c279503cd109d8a0]
        source-hash-f21114332bf670ab7f8e9b0a7f4d83d436d8fd9e
    git bisect good 00c3cacafec11fdfbdf7f0c8c279503cd109d8a0
    # good: [5e1da738abc9f023f0c7bafcffc10d899b57a95b]
        source-hash-ef296e87b8afa1afdc08a23675658e0252dd2b86
    git bisect good 5e1da738abc9f023f0c7bafcffc10d899b57a95b
    # bad: [4f494de6bc4e4807e40cb0793c3f18b029cab36d]
        source-hash-35f70c86f2d75cca18a34b2290a71753b3910879
    git bisect bad 4f494de6bc4e4807e40cb0793c3f18b029cab36d
    # skip: [c8f58541eeed5737b27b22855eed8cf67d44541a]
        source-hash-8419fa8c28dd9c5f64a72d28d561b3817d781232
    git bisect skip c8f58541eeed5737b27b22855eed8cf67d44541a
    # good: [0b0db851d65730a5d8f363651d37c1b045782832]
        source-hash-5d47b83cef0b2d0486162989722b23e53eb0cdb1
    git bisect good 0b0db851d65730a5d8f363651d37c1b045782832
    # skip: [5fd8a74fb9ca7ad070433ce3510918802a3bcce1]
        source-hash-0442cd217645aa4fdd924e4c2e4f90a77f1fbbad
    git bisect skip 5fd8a74fb9ca7ad070433ce3510918802a3bcce1
    # bad: [a7d852ffb3609abddf82ba874ede763f7222e9b5]
        source-hash-ad50b9a8636e0ee2f3c80669e8dde96577b26c4e
    git bisect bad a7d852ffb3609abddf82ba874ede763f7222e9b5
    # good: [ab2030ba105fad184edc6a2c02cc77aacccfb9ba]
        source-hash-d9b45d0823a5f2af89f5e60862711648beeebfb2
    git bisect good ab2030ba105fad184edc6a2c02cc77aacccfb9ba
    # skip: [0dac36ca2a71aec3224f3b195e055e799b734227]
        source-hash-9964b4087924777d2bd585a5d6ce5c088ef65b65
    git bisect skip 0dac36ca2a71aec3224f3b195e055e799b734227
    # good: [8d7a017c57d61ac1b644554e8f5a4882e1fb22ff]
        source-hash-853c2fc71a96755a9dee629fd5d0e1cff9a48034
    git bisect good 8d7a017c57d61ac1b644554e8f5a4882e1fb22ff
    # skip: [5e6c7fb196611594938560da2befcdd862fb3fd4]
        source-hash-e753d31d5d2338da35b69b0a3b7742420c7562d2
    git bisect skip 5e6c7fb196611594938560da2befcdd862fb3fd4
    # skip: [13704dc1c4aab2374a5fbfd5de45eba0eb7b128d]
        source-hash-05e7b1db351ee964d155e49c55de7db3c917083f
    git bisect skip 13704dc1c4aab2374a5fbfd5de45eba0eb7b128d
    # skip: [4bbc37c608b7517dba9e5665f1b4dbb1fec96157]
        source-hash-4c752c44f8a0857c4f2dbd61aff6b2d10cf3b5e5
    git bisect skip 4bbc37c608b7517dba9e5665f1b4dbb1fec96157
    # skip: [5f26656bc6c2bcbd233071041729d9a5ff677f34]
        source-hash-fcecc1fcb4a971a08d1e1fa5767bc5d93393a504
    git bisect skip 5f26656bc6c2bcbd233071041729d9a5ff677f34
    # only skipped commits left to test
    # possible first bad commit: [a7d852ffb3609abddf82ba874ede763f7222e9b5]
        source-hash-ad50b9a8636e0ee2f3c80669e8dde96577b26c4e
    # possible first bad commit: [5f26656bc6c2bcbd233071041729d9a5ff677f34]
        source-hash-fcecc1fcb4a971a08d1e1fa5767bc5d93393a504
    # possible first bad commit: [5e6c7fb196611594938560da2befcdd862fb3fd4]
        source-hash-e753d31d5d2338da35b69b0a3b7742420c7562d2
    # possible first bad commit: [13704dc1c4aab2374a5fbfd5de45eba0eb7b128d]
        source-hash-05e7b1db351ee964d155e49c55de7db3c917083f
    # possible first bad commit: [5fd8a74fb9ca7ad070433ce3510918802a3bcce1]
        source-hash-0442cd217645aa4fdd924e4c2e4f90a77f1fbbad
    # possible first bad commit: [c8f58541eeed5737b27b22855eed8cf67d44541a]
        source-hash-8419fa8c28dd9c5f64a72d28d561b3817d781232
    # possible first bad commit: [0dac36ca2a71aec3224f3b195e055e799b734227]
        source-hash-9964b4087924777d2bd585a5d6ce5c088ef65b65
    # possible first bad commit: [4bbc37c608b7517dba9e5665f1b4dbb1fec96157]
        source-hash-4c752c44f8a0857c4f2dbd61aff6b2d10cf3b5e5

I am removing keyword bibisectRequest and adding bibisected.
Comment 21 Justin L 2016-12-12 12:36:15 UTC
The specific commit was https://cgit.freedesktop.org/libreoffice/core/commit/?id=162c72d64077d9e0dae820d881ce2b56a5b2040c
author	Caolán McNamara <caolanm@redhat.com>	2015-01-23 13:17:39 (GMT)
Related: fdo#78599 ensure RegisterFormat is called before SetModified

and the related https://cgit.freedesktop.org/libreoffice/core/commit/?id=ad50b9a8636e0ee2f3c80669e8dde96577b26c4e
Related: fdo#78599 wrong method [where rNdTbl.RegisterToFormat(*pTableFmt) was added to the wrong ::TextToTable]

There are 4 ::TextToTable functions in here.  It looks like it was removed from
SwDoc::TextToTable( const SwInsertTableOptions& rInsTblOpts,
and added to
SwNodes::TextToTable( const SwNodes::TableRanges_t & rTableNodes,

CC Caolán
Comment 22 Justin L 2016-12-12 14:08:06 UTC
(In reply to Justin L from comment #21)
> There are 4 ::TextToTable functions in here.  It looks like it was removed
> from
> SwDoc::TextToTable( const SwInsertTableOptions& rInsTblOpts,
> and added to
> SwNodes::TextToTable( const SwNodes::TableRanges_t & rTableNodes,

bad conclusion.  It was removed from both SwDoc::TextToTables, and added to both SwNodes::TextToTables.

In this particular document, it first goes through SwNodes::TextToTable, and then SwDoc::TextToTable.  Registering earlier in SwNodes results in the regression demonstrated in this bug.
Comment 23 Xisco Faulí 2016-12-12 19:54:51 UTC
Adding Cc: to Caolán McNamara
Comment 24 Commit Notification 2016-12-13 14:11:24 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c117ab838b49b355a3f3fa48632a43284c989ffa

Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Caolán McNamara 2016-12-13 14:22:47 UTC
backports will follow
Comment 26 Commit Notification 2016-12-13 20:57:46 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7bc3175ad1fddf71c2a0108541e538f82872579a&h=libreoffice-5-3

Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977

It will be available in 5.3.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 Terrence Enger 2016-12-14 16:57:23 UTC
I see the bug is fixed in daily Linux dbgutil bibisect repository
version 2016-12-14.
Comment 28 Commit Notification 2016-12-20 05:16:07 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4d4fbeb623013f6377b30711ceedb38ea4b49f8&h=libreoffice-5-2

Resolves: tdf#103938 replace fix for tdf#78599/tdf#87977

It will be available in 5.2.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.