Bug 150927 - export of table in frame in table in header silently drops inner table
Summary: export of table in frame in table in header silently drops inner table
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: odf target:7.5.0 target:7.4.2 target:...
Keywords: dataLoss
Depends on:
Blocks:
 
Reported: 2022-09-13 10:28 UTC by Caolán McNamara
Modified: 2022-10-04 18:20 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
demo (10.06 KB, application/vnd.oasis.opendocument.text)
2022-09-13 10:29 UTC, Caolán McNamara
Details
Demo saved in 7.0.0 - ready to test (10.15 KB, application/vnd.oasis.opendocument.text)
2022-09-13 11:52 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Caolán McNamara 2022-09-13 10:28:22 UTC
Description:
Export of table in frame (anchored as char) in table in header silently drops inner table on export to .odt

Steps to Reproduce:
1. open attached file
2. select "TABLE"
3. table, insert table
4. export as odt
5. load exported odt

Actual Results:
the inner table has disappeared

Expected Results:
retain the inner table


Reproducible: Always


User Profile Reset: No



Additional Info:
This asserts in trunk since https://gerrit.libreoffice.org/c/core/+/127548 but the missing inner table appears to be happening since:

commit 35021cd56b3b4e38035804087f215c80085564be
Date:   Wed Aug 5 11:16:32 2020 +0300

    tdf#124470: Split export of table autostyles out from collection phase
Comment 1 Caolán McNamara 2022-09-13 10:29:52 UTC
Created attachment 182403 [details]
demo

need to select "TABLE" here and use table, insert table and then try to export as odt (will assert in trunk, but 7.2/7.3 don't) and then reload and inner table is missing
Comment 2 Mike Kaganski 2022-09-13 11:52:54 UTC
Created attachment 182407 [details]
Demo saved in 7.0.0 - ready to test

This is the demo from comment 1, with the steps followed, saved in 7.0.0 - so the inner table is saved correctly.

Now only save it in later versions and reload, to see the innermost table loss.
Comment 3 Rafael Lima 2022-09-13 14:45:39 UTC
Repro with

Version: 7.3.5.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1
Calc: threaded

Also repro with

Version: 7.5.0.0.alpha0+ / LibreOffice Community
Build ID: 641d92a73e5b3d0e062e16ed4b42236e1a4796a5
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Calc: threaded

The inner table indeed disappears after saving it as ODT and reopening the file.
Comment 4 Mike Kaganski 2022-09-14 06:00:04 UTC
https://gerrit.libreoffice.org/c/core/+/139901
Comment 5 Commit Notification 2022-09-14 08:39:31 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/58cb4fc7d17ae5b339c5ed6ae139e6ef2433c927

tdf#150927: properly handle nesting in tables

It will be available in 7.5.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 6 Commit Notification 2022-09-14 12:15:17 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/ec447be0adc32a16af02732fab4af22bc17e02cd

tdf#150927: properly handle nesting in tables

It will be available in 7.4.2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2022-09-15 08:10:05 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/c43b50bf027def7054bc15187d61d61d9b132bd7

tdf#150927: properly handle nesting in tables

It will be available in 7.3.7.

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

Affected users are encouraged to test the fix and report feedback.
Comment 8 Caolán McNamara 2022-09-20 14:28:49 UTC
I don't know if its a different problem, but FWIW https://bugs.documentfoundation.org/attachment.cgi?id=148210 (from bug 122628) still asserts on export to odt
Comment 9 Mike Kaganski 2022-09-21 06:32:13 UTC
(In reply to Caolán McNamara from comment #8)

As you mentioned,

> This asserts in trunk since https://gerrit.libreoffice.org/c/core/+/127548

The export of master styles (note that it's not content) started to require that *autostyles* are already collected, which is IMO wrong (autostyles should refer to styles) after that change. If there is a need to re-arrange the export logic because of that change, I suppose Vasily or Michael know the context of their change better; but I suggest that the rest is a separate bug.
Comment 10 Michael Stahl (allotropia) 2022-10-04 18:04:24 UTC
(In reply to Mike Kaganski from comment #9)
> (In reply to Caolán McNamara from comment #8)
> 
> As you mentioned,
> 
> > This asserts in trunk since https://gerrit.libreoffice.org/c/core/+/127548
> 
> The export of master styles (note that it's not content) started to require
> that *autostyles* are already collected, which is IMO wrong (autostyles
> should refer to styles) after that change. If there is a need to re-arrange
> the export logic because of that change, I suppose Vasily or Michael know
> the context of their change better; but I suggest that the rest is a
> separate bug.

it's rather non-obvious but this is expected: master styles contain part of the page styles (style:master-page), with their headers/footers that have text content, and this content may of course use automatic styles.

perhaps this is why the master-styles element exists, and the master-page element is separate from the page style (style:style family="page")?

thanks for fixing this in any case.
Comment 11 Michael Stahl (allotropia) 2022-10-04 18:20:42 UTC
(In reply to Caolán McNamara from comment #8)
> I don't know if its a different problem, but FWIW
> https://bugs.documentfoundation.org/attachment.cgi?id=148210 (from bug
> 122628) still asserts on export to odt

exports fine here with commit 21d93d8d2ffd9c5d5cfe9064590b35e0727295c9

guessing it was bug 151100