Created attachment 99971 [details] table cell comparison between Writer 4.3 beta and Word 2010 While reviewing attachment 97273 [details] in bug 77374, i noticed that in the latest releases of 4.0 - 4.2 and 4.3 beta, opening the file looses the 2 tables on page 1, though the table data isnt lost. It is a regression, as it works correctly in 3.6 and 4.2.2.1.
I can confirm in 4.2.5.1 and 4.3.0 beta1. Table in the first page is imported as text. Set to NEW. Importance: High/Major.
bibisected: 98e26b741cd0eff4b7549d782d7db5a1e98eb1a6 is the first bad commit commit 98e26b741cd0eff4b7549d782d7db5a1e98eb1a6 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 08:43:40 2012 +0000 source-hash-c29af1572ad15ac5199a09e5812fb8354c165329 commit c29af1572ad15ac5199a09e5812fb8354c165329 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Aug 22 14:20:32 2012 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Aug 22 14:20:52 2012 +0100 Resolves: rhbz#842292 crash in calling callback whose instance was deleted Change-Id: I4cc04d59f48b42cc105703daa9983dd7c9f7af62 :100644 100644 f48bbaa1aee4fff06b03f00d856ea90afc8f4bb1 4ef31fbafb0c6fd5facf46ad5e5f2c3151b7a150 M autogen.log :100644 100644 77e291a56c8feedd3992dd9c5917420647c9e573 2fe83a37019bb77da337c19f71e03604047b3f5a M ccache.log :100644 100644 dd86cf323227505bc8de0a58a14c1512687e5fa0 317825a87e2d4a9fc5e5037476a32d63a9008767 M commitmsg :100644 100644 8c0b0ea815bd74a322e365f8f118851ab08188f7 5916ce4e398448c1077ea677f9d0271c22a8f7e5 M dev-install.log :100644 100644 76bb1bc9512a65c3fd17fdfb8ded49c13d9ddde8 30ec6ef53acbb8a12c35651e909582d0a870a41b M make.log :040000 040000 45f170a51889800a6518fc1f3ecad287e19cc8dc fac44c717ea5908b4edd59ad684c8de62987ee88 M opt # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # bad: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect bad 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [446a69834acf747d9d18841ec583512ae8fa42e7] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f git bisect bad 446a69834acf747d9d18841ec583512ae8fa42e7 # bad: [d2720e99b9e6cb7b099256cc7a6d2b3f907b8d7c] source-hash-7dd6c0a8372810f48e6bee35a11ac4ad0432640b git bisect bad d2720e99b9e6cb7b099256cc7a6d2b3f907b8d7c # bad: [98e26b741cd0eff4b7549d782d7db5a1e98eb1a6] source-hash-c29af1572ad15ac5199a09e5812fb8354c165329 git bisect bad 98e26b741cd0eff4b7549d782d7db5a1e98eb1a6 # good: [a72763112e846bcb1c4e4c6f1612ccab6ac73772] source-hash-4662df8a7561ce71ba00accbb5170e10818d6008 git bisect good a72763112e846bcb1c4e4c6f1612ccab6ac73772 # good: [241d451e09694446622f9767fb76db50481c9e32] source-hash-c3aa1cefdc6521d34a2a32c20bae1593e1edb5ba git bisect good 241d451e09694446622f9767fb76db50481c9e32 # first bad commit: [98e26b741cd0eff4b7549d782d7db5a1e98eb1a6] source-hash-c29af1572ad15ac5199a09e5812fb8354c165329
regression from: commit edc4861a68e0269b83b17e0ec57912a1ce4220ad Author: Miklos Vajna <vmiklos@suse.cz> AuthorDate: Wed Aug 15 16:31:51 2012 +0200 n#775899 initial docx import of w:vertAnchor inside w:tblpPr
(This is an automated message.) It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Just confirmed it is still present in 4.4 daily and the file wont open in master (bug 89100). Version: 4.4.1.0.0+ Build ID: 2b325c5c009c1a73345520c03ffbf03dc4600eff TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:libreoffice-4-4, Time: 2015-01-22_19:47:54
Migrating Whiteboard tags to Keywords: (bibisected, dataLoss)
Adding Cc: to Miklos Vajna
*** This bug has been marked as a duplicate of bug 61594 ***
Definitely not a duplicate of bug 61594, although it seems to be related. This bug focuses on the loss of the table frames. The lost table was fixed sometime earlier (so the 4.0 bibisect in comment 2 is not really correct). The most recent break occurs from this commit in the 4.3 branch. commit e5fd7c2dacf3c128cdc62622e736ce8abbc578a5 Author: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Mon Feb 17 09:56:36 2014 +0100 fdo#74357 DOCX import: fix nested tables anchored inside tables Regression from bbef85c157169efa958ea1014d91d467cb243e6f (bnc#779620 DOCX import: try harder to convert floating tables to text frames, 2013-10-01), the conversion of nested tables is delayed by default till we know the page size. However, in case the anchor is in a table, we should convert it right away, because the conversion of the parent table would invalidate our XTextRange references. Change-Id: Id41556e721c6e1c7239e4ea25abd57c999d2219b
Hi Justin, great work. Thanks for your clarifying.
Created attachment 127667 [details] bandaid patch fixes this particular document but doesn't address the real problem. Attached a patch to jumpstart an expert developer. An exception in the last row (containing another table with the 4 moon phases) is causing the table-end never to run (in addition to other layout problems).
The problem is that in case the nested floating table is anchored at the start of the cell, then creating the text frame of the table invalidates the start position of the outer table cell, so table conversion for the outer table fails. As a fix for the regression I'll disable the floating table conversion in this "anchored at the start of a cell" case; that should fix the regression without reverting the whole "import floating table from docx" feature. (In the long run, it would be nice to find a way to execute the text frame conversion without killing the cell start/end ranges, but that's more complicated.)
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1eebcdac9f2b289fd363399130c485ca5ff444c tdf#79329 DOCX import: fix missing outer table with floattable at cell start It will be available in 5.3.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.
Miklos, please also comment on backporting.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d6e89673155c9cb536747c734b2de23f3d8484ef&h=libreoffice-5-2 tdf#79329 DOCX import: fix missing outer table with floattable at cell start It will be available in 5.2.4. 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.
*** Bug 93874 has been marked as a duplicate of this bug. ***
*** Bug 93621 has been marked as a duplicate of this bug. ***