Bug 127412 - FILEOPEN: ODT: z-order of shapes is interpreted wrongly
Summary: FILEOPEN: ODT: z-order of shapes is interpreted wrongly
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.4.0 target:6.3.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-09-06 15:45 UTC by Regina Henschel
Modified: 2019-12-20 11:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Shapes with z-order (10.15 KB, application/vnd.oasis.opendocument.text)
2019-09-06 15:45 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2019-09-06 15:45:30 UTC
Created attachment 153993 [details]
Shapes with z-order

The shapes in the attached document have the order Frame1 (z-index 0), Frame2 (z-index 1), Frame3 (z-index 2). But on opening the shape of Frame3 is behind the shape of Frame2. Only the text box of Frame3 is shown in front of Frame2.
If the document is saved without anything changed, the z-order in the file is changed to this wrong rendering.

I see the error already in version 5.4.7, I have not tested earlier versions.
Comment 1 Julien Nabet 2019-09-06 19:36:45 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I noticed these logs on console:
warn:xmloff:23514:23514:xmloff/source/draw/ximpshap.cxx:691: DBG_UNHANDLED_EXCEPTION in void SdXMLShapeContext::SetStyle(bool)
    when: finding style for shape exception: com.sun.star.container.NoSuchElementException
warn:xmloff:23514:23514:xmloff/source/draw/ximpshap.cxx:691: DBG_UNHANDLED_EXCEPTION in void SdXMLShapeContext::SetStyle(bool)
    when: finding style for shape exception: com.sun.star.container.NoSuchElementException
warn:xmloff:23514:23514:xmloff/source/draw/ximpshap.cxx:691: DBG_UNHANDLED_EXCEPTION in void SdXMLShapeContext::SetStyle(bool)
    when: finding style for shape exception: com.sun.star.container.NoSuchElementException
Comment 2 Gerhard Weydt 2019-09-06 21:49:02 UTC
I can confirm the bug with LibO 5.1.6.1, 6.2.4.2 and 6.3.1.2, all on Windows 10, 64 Bit.
Bugs #120760, #81956, #72367 seem to be related.
Comment 3 Regina Henschel 2019-09-06 22:54:04 UTC
(In reply to Gerhard Weydt from comment #2)
> Bugs #120760, #81956, #72367 seem to be related.

I think none of them is related, because all of them have trouble with "in background" or what is "behindDoc" in OOXML. But here the problem is because of the feature "Add Textbox" to a custom shape. Such "Textbox" is a very special construct, were a custom shape gets properties of a frame.
Comment 4 Thomas Krumbein 2019-09-07 18:21:56 UTC
open file with Lo 5.3.1.2 64 bit on Win 10, reacts as descriped.

Save file (store as) and open it again, z-order ist ok, behaviour is correct.

But you can see another strange behavior:

select one of the shapes, select form context menu (or from standard menu - no difference): Anordnung (not shure of english expression - maybe "order"?) - in front... shape will be ordered in front, but the related textbox will disappear. No possibility to get it back (including content)!

this may be a more importend bug.
Comment 5 Gerhard Weydt 2019-09-07 19:35:36 UTC
In fact, the saved file is correct again.

As regards the "strange behaviour": the text box isn't lost, it's only hidden behind the shape! If you send the shape to back, you will see it again. You can also select the shape by drawing a rectangle with the mouse which does not cover the shape completey, and then use "bring Front" or "Forward one". This didn't always work with the context menu, but you can use Format ->Arrange...
This seems to the behaviour described in bug #124430.
Comment 6 Xisco Faulí 2019-09-18 10:12:51 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9835a5823e0f559aabbc0e15ea126c82229c4bc7

author	Miklos Vajna <vmiklos@collabora.co.uk>	2014-10-04 19:37:55 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2014-10-04 20:18:01 +0200
commit 9835a5823e0f559aabbc0e15ea126c82229c4bc7 (patch)
tree 12b77a17bf437e248ef02cc06634ab1dc458a99c
parent ad5e8b30ac66a00d0110fcdaf4d064181247585b (diff)
sw textboxes: reimplement ODF import/export

Bisected with: bibisect-44max

Adding Cc: to Miklos Vajna
Comment 7 Commit Notification 2019-10-22 06:45:37 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9a29a4df545d7f88cd14bb99ce54f149032eb7f0

tdf#127412 sw: fix reported ZOrder of shape+textbox pairs

It will be available in 6.4.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 8 Xisco Faulí 2019-10-23 09:39:19 UTC
Verified in

Version: 6.4.0.0.alpha1+
Build ID: 437dc68285dab0f08a1ded2193d86d64f560cd9b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Miklos, thanks for fixing this issue!!
Comment 9 Commit Notification 2019-10-23 09:41:57 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/47ec4fb42cae7e51e45c6361a6e6773462b7b8ca

tdf#127412 sw: fix reported ZOrder of shape+textbox pairs

It will be available in 6.3.4.

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.