Bug 119111 - Shapes losing position and z-index
Summary: Shapes losing position and z-index
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Shapes
  Show dependency treegraph
Reported: 2018-08-05 14:56 UTC by DM
Modified: 2019-03-05 14:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Exhibit document (8.83 MB, application/vnd.oasis.opendocument.text)
2018-08-23 21:05 UTC, DM

Note You need to log in before you can comment on or make changes to this bug.
Description DM 2018-08-05 14:56:50 UTC
I have a table with JPGs dragged in (usually two columns with some cells split into 4 using split cell). Over these pictures I have placed labels with arrows to annotate them.
The labels and arrows are constantly losing their position or z-index (spontaneously disappearing behind the JPGs) both during editing and also if I save the document and reopen it.
Every time I go to produce a PDF I have to go through all the arrows and labels and fix it (about 30-40% of them, only to have to repeat this for the next PDF generation).
It's pretty awful and it needs to be fixed as high priority.
The problem still exists on the latest release.

Steps to Reproduce:

Actual Results:

Expected Results:

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
CPU threads: 2; OS: Windows 10.0; UI render: default; 
Locale: en-GB (en_GB); Calc: grou
Comment 1 DM 2018-08-05 14:59:19 UTC
When the position has been lost rather than z-index the items often appear half off the right edge of the page.
Comment 2 Xisco Faulí 2018-08-15 18:28:39 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Comment 3 DM 2018-08-19 18:44:05 UTC
Thanks. When I've a moment I'll see if I can find a way to predictably reproduce it, as it does it a certain amount on several of my documents I've been making but I'm not convinced that they're 'systematically reproducible', rather than hard to predict.
They have in common that they rely on two-equal-column tables where the rows alternate between a merge across (for info) and below that the right hand column cells have been split into a square of four cells (combined left-right making 5 cells) and populated with (five) square images, then another across-merge for title and info, etc, and Text boxes with arrow lines overlaid, naturally getting shunted onto new pages when earlier material is added.
I'll aim to attach an exhibit in due course.
Cheers, David
Comment 4 Xisco Faulí 2018-08-20 16:26:46 UTC
Please, do, otherwise it's very difficult for us to investigate this issue...
Comment 5 DM 2018-08-23 21:05:52 UTC
Created attachment 144405 [details]
Exhibit document

This is an example of what's happening.
You'll see in the .odt a blue arrow directing where to look at. There you will see some faint yellow of some text from some text boxes which used to be variously above the photos but have lost their places and ended up under the pictures. More than that, you cannot fix it readily - if you send the picture at the end of the blue arrow to the z-order bottom they stay obscured, whilst if you click near the top corner of that picture it will select an invible textbox but if you raise it to the top you will not see it. To see it you have to delete the photo and you'll then see it behind.
I have also found from this problem lines/boxes going off the margin, which is not possible manually since you cannot go beyond the margin, and if they are completely over the margin then you cannot get to them with the cursor to retrieve them.
Cheers, David

Present Versioning:-
Version: (x64)
Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU threads: 2; OS: Windows 10.0; UI render: default; 
Locale: en-GB (en_GB); Calc: group threaded
Comment 6 DM 2018-08-23 21:14:00 UTC
There MAY perhaps be a connection to the units mismatch problem I've been encountering (which I've reported but not been able to provide repeatable steps for since it's unpredictable) wherein suddenly it changes to inches in the properties of a drawing element but the options continue to be unchanged at cms. I noticed this had happened in this exhibit when I created the blue arrow to point out the location to view. A confusion of units might throw the locations, but the textboxes are thrown differently from the arrows at times (but at other times they are both thrown out alike). However it wouldn't explain the z-order problems which suggest an edit somewhere is causing the imperfect recreation of drawing shapes. That said, they've also lost their position just by saving a document...
It does cause huge problems working with annotated pictures, as you can imagine.
Comment 7 DM 2018-08-23 21:19:39 UTC
Final comment - if you delete all the pictures, you'll then spot all the text boxes that used to be above the pictures that are now under them, some thrown (such as the circle), others not (such as "Upright Flowers"). d
Comment 8 Dieter Praas 2018-08-26 15:54:58 UTC
I tried to reproduce it

1. Open attachment from comment 5
2. Open navigator => drawing objects (shape 1; shape 2; shape 4)
3. Bring every shape to the forground
4. Save and close document
5. Reopen document => All shapes are still in foreground and have the same position

So I can't reproduce the bug with

Version: (x64)
Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04
Locale: en-US (de_DE); Calc: CL

If possible please describe alternative steps to reproduce.
Comment 9 DM 2018-08-26 16:04:57 UTC
I don't currently know a way of reproducing it on demand. The attachment was to show the result of the problems - shapes that have lost their position (on this one text shapes ending up at the top left corners of cells and z-index altered so that they end up under objects and not responding to a z-index change of sending-to-back/front). On other ones the text shapes are thrown over the right hand margins, which is impossible by hand.
I found a way to recover the text shapes in the attached exhibit which is to click in the top left corner of each of the cells and where there is one it will be highlighted but invisible and then clicking one of the wrap buttons makes it visible.
The saving comment was to illustrate how variable the problem is, as it may happen just by saving and reopening but that is a less frequent occurrance. Most commonly they lose their xy positions and z-index somewhere in the document as I'm editing, and it's very common.
Comment 10 DM 2018-08-26 16:57:42 UTC
(If I find specific reproducible steps I'll certainly post them. I was hoping the above symptoms would give some clues to be on the look-out for as you work with the code.)
Comment 11 Dieter Praas 2018-08-27 06:49:30 UTC
(In reply to DM from comment #10)
> (If I find specific reproducible steps I'll certainly post them. I was
> hoping the above symptoms would give some clues to be on the look-out for as
> you work with the code.)

I change to the status to NEEDINFO. Please change it back to UNCONFIRMED, if you know how to reproduce.
Comment 12 Alex Thurgood 2019-03-05 14:00:37 UTC
@DM : I've just come across this in Draw with LO6203 (but not before). I'll open a separate bug report for what I see and link to this, in case they're related.
Comment 13 Alex Thurgood 2019-03-05 14:04:02 UTC
So, in my case, I have and ODG file that contains JPG/PNG images (line images) over which have been drawn reference lines and numbering added (textboxes). This particular file was created in an earlier version of LO.

The file opens and displays correctly in LO6152.
However, if I open it in LO6203, all of the reference lines, that were previously ordered in front of the images, are now behind as are some of the reference numerals (those whose textbox overlapped with the image boundaries).