Bug 68745 - TABLE: Wrong cells are merged
Summary: TABLE: Wrong cells are merged
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2013-08-30 07:38 UTC by Kent S
Modified: 2016-12-28 17:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
A test document, to reproduce the bug/problem. (19.13 KB, application/vnd.oasis.opendocument.text)
2013-08-30 07:38 UTC, Kent S
Details
simplified test document to reproduce the bug (11.63 KB, application/vnd.oasis.opendocument.text)
2015-08-06 23:58 UTC, Michael Weghorn
Details
screenshot of merged cell at the top of the table (9.14 KB, image/png)
2015-08-07 15:16 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kent S 2013-08-30 07:38:28 UTC
Created attachment 84899 [details]
A test document, to reproduce the bug/problem.

Problem description: 
In a table, I want to merge two cells. I select the cells, and click the "merge"-button. Then one of the selected cells are merged with the cell in the row above, that is not selected. And the rows are switched. If I made a new document, I have not been able to reproduce the problem. So please try in the attached document.

Steps to reproduce:
1. Open my attached document "table bug.odt"
2. On page one, select the two cells with yellow background, named "This one!" and "and this one!".
3. Press the merge button.
4. Note the row numbers to the left. They was 401, 402, 403, 404, 405, 406 and now they are 401, 402, 404, 403, 405

Another strange behavior:
1. Open the document.
2. Select the two cells, and the cell above. You now have three cells selected.
3. Press the merge button.
4. The cell on row 402 is not merged!

Current behavior:
The rows are messed up. WHen mergeing two cells, the cells under will also be merged with the cell to the right.

Expected behavior:
The selected cells should merge, and the rows should be in the same order as before. :)
              
Operating System: Windows 7
Version: 4.0.4.2 release
Comment 1 Thomas van der Meulen 2013-08-30 07:48:35 UTC
Thank you for your bug report, I CAN'T reproduce this bug running Version: 4.1.1.2
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 on Mac osx 10.8.4. 

I can reproduce the 2 problem that you said.
Comment 2 Kent S 2013-08-30 10:00:52 UTC
(In reply to comment #1)
> Thank you for your bug report, I CAN'T reproduce this bug running Version:
> 4.1.1.2
> Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903 on Mac osx 10.8.4. 
> 
> I can reproduce the 2 problem that you said.

Sorry, the version may be wrong in my report. Here is the version I use, that I have problem with:
Version: 4.1.1.2
Build ID: 7e4286b58adc75a14f6d83f53a03b6c11fa2903
Comment 3 QA Administrators 2015-04-01 14:42:06 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-04-24 12:03:01 UTC
I could not reproduce it in 3.4.3.
3.5.0 crashed when merging, but I managed to see, that it didn't mess up the numbers.

3.6.3.2 showed the problem.

Adding bibisect request anyway, because maybe there is something wrong in my end. I'm using the new releases repo: https://wiki.documentfoundation.org/QA/HowToBibisect#releases
Comment 5 Buovjaga 2015-04-24 12:06:37 UTC
(In reply to Beluga from comment #4)
> I could not reproduce it in 3.4.3.
> 3.5.0 crashed when merging, but I managed to see, that it didn't mess up the
> numbers.
> 
> 3.6.3.2 showed the problem.
> 
> Adding bibisect request anyway, because maybe there is something wrong in my
> end. I'm using the new releases repo:
> https://wiki.documentfoundation.org/QA/HowToBibisect#releases

These were on Linux..

I remembered I had 3.5.0rc3 on Windows as well and it didn't crash and did not show the problem!

The problem persists in the latest version:
Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64)
Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50
Locale: fi_FI
Comment 6 Michael Weghorn 2015-08-06 23:58:36 UTC
Created attachment 117728 [details]
simplified test document to reproduce the bug

I attach a simplified sample document where the bug occurs but the crash should not happen.
Comment 7 Michael Weghorn 2015-08-07 15:15:01 UTC
While bibisecting the bug using the "bibisect-43all" repository and the simplified sample file, I found out that the behaviour does not change at once from being correct to the behaviour described in the bug report. It works correctly with old versions of LibreOffice (e.g. commit tagged "oldest" in bibisect-43all repository).

There are 3 changes in the behaviour. The different "steps" are the following:

A) The content of the two cells is merged correctly, but the merged cell is moved to the top of the table (s. screenshot "A_screenshot_merged_cell_at_top.png")
B) Instead of merging the two cells, the content of both cells is removed. No cells are merged.
C) The behaviour as described in this bug report can be observed.

I bibisected all of those changes in the behaviour.

=============================

Bibisect result for transition "OK -> A" (i.e. cell content merged, but at wrong position):

 6d50aa5efc5cd2c6ebbb903f794de6d7033dab06 is the first bad commit
commit 6d50aa5efc5cd2c6ebbb903f794de6d7033dab06
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Dec 8 17:31:39 2011 +0100

    source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75
    
    commit f82da782158d8f5b89a6a9057df1a4695425ed75
    Author:     awf <af@openoffice.org>
    AuthorDate: Tue Nov 1 16:18:25 2011 +0000
    Commit:     Thorsten Behrens <tbehrens@suse.com>
    CommitDate: Wed Nov 23 23:53:50 2011 +0100
    
        i118560 - slide sorter: pass PageSelector object by reference
    
         * found as LGPLv3-only fix at svn rev 1196092 (http://svn.apache.org/viewvc?view=revision&revision=1196092)

:100644 100644 9dbb685a6c533c88b46a30cde0a1b1a94609db9f 84bd40e7115c984ed43af55b7ceb2bf4908871ee M	autogen.log
:100644 100644 ff513f43b053cd08436e95828392c55a3bd6c644 99e02690ea7cf8c2db142cf5b6216cdbd47c557e M	ccache.log
:100644 100644 d22037618bba9cd63b9c52f393a87ff22cac1f67 b52c1b3c7e023af0553af0f0b57e4e665b73ed93 M	commitmsg
:100644 100644 a0fc2f98774473b8813004b0b8778946523434b8 26355b533ace03b1859603af068de3962256530d M	dev-install.log
:100644 100644 e015e09e4af4ff63d73d61d47646f26cb44670a5 af4f4544d46fbb7a224096e9b9bad031ed080a2f M	make.log
:040000 040000 9abf646ea68e7bd435383d24d9cb7222e938788e 811fdb22c8768b44c1b09a40f82ab644bad0445c M	opt

---

$ git bisect log
# bad: [6d50aa5efc5cd2c6ebbb903f794de6d7033dab06] source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start '6d50aa5efc5cd2c6ebbb903f794de6d7033dab06' 'oldest'
# good: [bb6eff0592390dcc81fd5ffe70d99f57c8cb882d] source-hash-62f4128d74179c6211fc961845182bf2956e3323
git bisect good bb6eff0592390dcc81fd5ffe70d99f57c8cb882d
# good: [67977e7d09cb355e3503197b66c680da12d42b2a] source-hash-a57304a53832adf0c8a32b0c53d9be5b55507ab1
git bisect good 67977e7d09cb355e3503197b66c680da12d42b2a
# good: [b658339d2664dc336ab5be96154740b06c187c86] source-hash-ae78e3e913f39e2cc6d2b6f83f38c2ea225ab53e
git bisect good b658339d2664dc336ab5be96154740b06c187c86
# good: [93f7cbc3a56164ce23d3d586a0611df6606fb3b2] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42
git bisect good 93f7cbc3a56164ce23d3d586a0611df6606fb3b2
# good: [3a7ba13e401ac1314a63aede2dfb1f7168332d99] source-hash-ab63c12395ed3771b1df6822eaa8572c06db0765
git bisect good 3a7ba13e401ac1314a63aede2dfb1f7168332d99
# first bad commit: [6d50aa5efc5cd2c6ebbb903f794de6d7033dab06] source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75

=============================

Bibisect result for transition "A -> B" (i.e. cells not merged, content removed):

 761fff35524e6ab47f64d43482d6a9dc06035e86 is the first bad commit
commit 761fff35524e6ab47f64d43482d6a9dc06035e86
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Dec 8 19:10:55 2011 +0100

    source-hash-919abbfe9b1461e4accbdebe4a2475379d2d5731
    
    commit 919abbfe9b1461e4accbdebe4a2475379d2d5731
    Author:     August Sodora <augsod@gmail.com>
    AuthorDate: Sat Nov 26 15:24:38 2011 -0500
    Commit:     August Sodora <augsod@gmail.com>
    CommitDate: Sat Nov 26 18:13:26 2011 -0500
    
        Avoid use of the preprocessor

:100644 100644 99e02690ea7cf8c2db142cf5b6216cdbd47c557e bde27849ead164de3c14acbb98da0a2939a031a1 M	ccache.log
:100644 100644 b52c1b3c7e023af0553af0f0b57e4e665b73ed93 3a11eeb9a978e1babe919a273db1d6014f0dcd85 M	commitmsg
:100644 100644 26355b533ace03b1859603af068de3962256530d 1e3b5ab2f8e24cfc0e3045f8cc688fd40603727c M	dev-install.log
:100644 100644 af4f4544d46fbb7a224096e9b9bad031ed080a2f 8cbe5809c07f4e7a93f8c2d9c294d8056d7ff3fc M	make.log
:040000 040000 811fdb22c8768b44c1b09a40f82ab644bad0445c aaa89d63858edde423061d11ab7f0f59e627166c M	opt

---

$ git bisect log
# bad: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
# good: [6d50aa5efc5cd2c6ebbb903f794de6d7033dab06] source-hash-f82da782158d8f5b89a6a9057df1a4695425ed75
git bisect start 'last35onmaster' '6d50aa5efc5cd2c6ebbb903f794de6d7033dab06'
# bad: [351622aec2dff3cc3bbbb020ad0097c4322d2a21] source-hash-2c4537471c932b65e6f72e41881b505c4bbad12c
git bisect bad 351622aec2dff3cc3bbbb020ad0097c4322d2a21
# bad: [9129c082f5b2d5de76f6492cc51def8c97397580] source-hash-ab407ad86610a0aba882b03075319e0b62b2c8d3
git bisect bad 9129c082f5b2d5de76f6492cc51def8c97397580
# bad: [761fff35524e6ab47f64d43482d6a9dc06035e86] source-hash-919abbfe9b1461e4accbdebe4a2475379d2d5731
git bisect bad 761fff35524e6ab47f64d43482d6a9dc06035e86
# first bad commit: [761fff35524e6ab47f64d43482d6a9dc06035e86] source-hash-919abbfe9b1461e4accbdebe4a2475379d2d5731


=============================

Bibisect result for transition "B  -> C" (i.e. behaviour as described in the bug report):
 b2c3b987024faeeabd2e45187cb08b5eee4c4629 is the first bad commit
commit b2c3b987024faeeabd2e45187cb08b5eee4c4629
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun Dec 9 10:01:11 2012 +0000

    source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac
    
    commit a90d7788a4b9aca4378cd1660293403db3d399ac
    Author:     Matúš Kukan <matus.kukan@gmail.com>
    AuthorDate: Sat May 5 14:47:15 2012 +0200
    Commit:     Matúš Kukan <matus.kukan@gmail.com>
    CommitDate: Sat May 5 16:23:10 2012 +0200
    
        fix typo
    
        Change-Id: Ie8987092a63e9a3b5d3b94f7ae54fbef98fdfc2c

:100644 100644 2a41905990ab8d65e03878c3cd6450dc2b328165 709fc38885d14fa36c79d0ffd56697732aaeb1e9 M	autogen.log
:100644 100644 eabeaf3d34d05774c496b5584282c48ae8c0da01 f9e38ceeb82e907f35251af8eb5048a3b0badf69 M	ccache.log
:100644 100644 1a0108dc6a39a69f9834cfbd10b7d6e1adc59333 af80ad8491640fbf2e789dc9c18ca2f95e7a53ae M	commitmsg
:100644 100644 e1412f59d4a8d4269f0dd5cbb0d32406f596bb0e 5480044878c3a4ef7822e2c23b52e485df07f8d0 M	dev-install.log
:100644 100644 7501639183011cc5664425c97de14d06a231e47a ef1e0e5a2ab7a64919c1b733828d6b413e1124fe M	make.log
:040000 040000 b78cd837c04c22973606d712c84aa41280bb03d4 6015723cc86af1fe3db81770464664915b88868b M	opt

--- 
$ git bisect log
# bad: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
# good: [cf86b7f14a98d2d81a5cd93507acb35ff6775d8b] source-hash-85c6244b85b29c1d2bb9d89b62e9512dd65378b5
git bisect start 'last40onmaster' 'last35onmaster'
# bad: [69497016bae6f296c763f76670153dbe6a2f265d] source-hash-bed3049c4c04a202ff288189d225ca6e5941d69b
git bisect bad 69497016bae6f296c763f76670153dbe6a2f265d
# good: [d34ee3a09f92a227563b358199072404148f7a3a] source-hash-1856186951a70a0bcac4e0c3632ca4afe68c05e3
git bisect good d34ee3a09f92a227563b358199072404148f7a3a
# bad: [aed6d9e275e4560aa251d23dd7ba6a0a725afab7] source-hash-c77918bb03974ff9be90c889f77e62ea0755052f
git bisect bad aed6d9e275e4560aa251d23dd7ba6a0a725afab7
# good: [b119645386363b75d60215f91775cba82c1c6126] source-hash-3b328186706e6819acfea7b3a6dc8c9d3b6f9693
git bisect good b119645386363b75d60215f91775cba82c1c6126
# bad: [8b099bdbf262cdc405279bb8058b1beb14e3e8f3] source-hash-ef7a460fa51140782b7ad4d87aa782ca007c56ca
git bisect bad 8b099bdbf262cdc405279bb8058b1beb14e3e8f3
# bad: [b2c3b987024faeeabd2e45187cb08b5eee4c4629] source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac
git bisect bad b2c3b987024faeeabd2e45187cb08b5eee4c4629
# good: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf
git bisect good 8a39227e344637eb7154a10ac825d211e64d584c
# first bad commit: [b2c3b987024faeeabd2e45187cb08b5eee4c4629] source-hash-a90d7788a4b9aca4378cd1660293403db3d399ac
Comment 8 Michael Weghorn 2015-08-07 15:16:03 UTC
Created attachment 117751 [details]
screenshot of merged cell at the top of the table
Comment 9 Robinson Tryon (qubit) 2015-12-13 11:16:17 UTC Comment hidden (obsolete)
Comment 10 Telesto 2016-12-21 12:36:31 UTC
No repro with:
Version: 5.4.0.0.alpha0+
Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02
Locale: nl-NL (nl_NL); Calc: CL
Comment 11 Buovjaga 2016-12-28 17:50:13 UTC
(In reply to Michael Weghorn from comment #7)
> There are 3 changes in the behaviour. The different "steps" are the
> following:
> 
> A) The content of the two cells is merged correctly, but the merged cell is
> moved to the top of the table (s. screenshot
> "A_screenshot_merged_cell_at_top.png")
> B) Instead of merging the two cells, the content of both cells is removed.
> No cells are merged.
> C) The behaviour as described in this bug report can be observed.

I cannot see any of the problems with the simplified example or the original. WFM.

Version: 5.4.0.0.alpha0+
Build ID: 53edf60c4ce6ed32f87471e018878c40b788005a
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-12-18_07:01:05
Locale: fi-FI (fi_FI); Calc: group