Bug 119111 - Shapes losing position and z-index
Summary: Shapes losing position and z-index
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shapes
  Show dependency treegraph
 
Reported: 2018-08-05 14:56 UTC by DM
Modified: 2020-05-01 20:09 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Exhibit document (8.83 MB, application/vnd.oasis.opendocument.text)
2018-08-23 21:05 UTC, DM
Details
Move-Undo example of unrelated item jumping (18.15 MB, application/vnd.oasis.opendocument.text)
2019-12-02 10:13 UTC, DM
Details
Cut-Doc-and-Repaste to give shapes unique names issue (8.83 MB, application/vnd.oasis.opendocument.text)
2019-12-04 11:26 UTC, DM
Details

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
Description:
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.
Cheers

Steps to Reproduce:
.

Actual Results:
.

Expected Results:
.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.0.5.2 (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.
d
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: 6.1.0.3 (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.
d
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 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: 6.2.0.0.alpha0+ (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.
d
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 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).
Comment 14 QA Administrators 2019-09-02 09:30:02 UTC Comment hidden (obsolete)
Comment 15 Regina Henschel 2019-09-02 10:27:24 UTC
You need to take care, that all objects have unique names. In your attached document several objects have the same name. Please test, whether you see the problem too, if you have corrected the names.
Comment 16 DM 2019-12-02 10:04:28 UTC
That is an extremely enlightening comment, and I apologise for just noticing it now. Surely if name is critical to operations, then it's a bug in itself for two objects to have the same name (like two people having the same national identity number) or so easily to do so? how could it happen? I copy items to duplicate them all the time, would you be suggesting that copying them retains the same name (just tried it and it seems so!) and that I need to rename every item I copy? that sounds an extraordinary deficiency to me, since copying drawing objects like arrows and text boxes to reuse is something you do all the time to maintain a common style throughout a document. What sort of complications occur through having objects the same name in terms of everyday document-making? Are there occasions when two items having the same name are useful? if not, shouldn't copies just generate new names?
I would be very keen to hear your reply here, since the whole situation of Libreoffice constantly mangling everything up drives me crazy... thanks!
David

(In reply to Regina Henschel from comment #15)
> You need to take care, that all objects have unique names. In your attached
> document several objects have the same name. Please test, whether you see
> the problem too, if you have corrected the names.
Comment 17 DM 2019-12-02 10:13:20 UTC
Created attachment 156239 [details]
Move-Undo example of unrelated item jumping

Here is another example of the sort of problem on my doc I am updating, and several related examples have been posted in the past in the comments (so I've changed it to Unconfirmed).
On p3, move the arrow under "Long Awns" to be over the picture on its left (i.e. move it to be under "Flowerhead reaches upper leaf base" then click Ctrl-Z to undo the act. You'll see not only does it move back, but a completely random item from elsewhere in the document jumps there too. This is quite a common occurrence.

Version: 6.3.2.2 (x64)
Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded
Comment 18 DM 2019-12-02 10:14:48 UTC
Example added 'Move-Undo example of unrelated item jumping'
Comment 19 Regina Henschel 2019-12-02 12:27:40 UTC
(In reply to DM from comment #16)
> That is an extremely enlightening comment, and I apologise for just noticing
> it now. Surely if name is critical to operations, then it's a bug in itself
> for two objects to have the same name (like two people having the same
> national identity number) or so easily to do so? how could it happen? I copy
> items to duplicate them all the time, would you be suggesting that copying
> them retains the same name (just tried it and it seems so!) and that I need
> to rename every item I copy?

Yes, in your version of LibreOffice you have to rename each shape immediately after copying it.

> that sounds an extraordinary deficiency to me,

The developers have noticed, that this is indeed a problem, and have fixed it. The fix will surely be in the upcoming version 6.4. I don't know whether a bug fix release of the 6.3 family will have it.

You can try the prerelease of version 6.4.0. Use https://www.libreoffice.org/download/download/ and scroll down to the end of the page. You need to do an "administrative installation" for to not touch your current installation. https://wiki.documentfoundation.org/Installing_in_parallel
Comment 20 DM 2019-12-03 11:22:50 UTC
That's really great news to hear, if it's causing problems. I'll try to give it an early whirl but look forward to the stable one coming out, and I'll see especially if that fixes any of the many drawing issues.
I am assuming (am I right?) that the fixed version will on opening a document automatically check for name duplication and rename the shapes so their IDs are all unique.
Thank you very much,
David
Comment 21 Dieter 2019-12-03 17:18:28 UTC
(In reply to DM from comment #20)
> That's really great news to hear, if it's causing problems. I'll try to give
> it an early whirl but look forward to the stable one coming out

6.4.0.0beta1 will be installes in parallel, so you don't have to be worry about your documents.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 22 DM 2019-12-04 00:00:43 UTC
Hello!
I've just installed the beta.
1. For new shapes it does generate new names on copy.
2. The existing shapes that all have the same name it doesn't rectify on opening, which it will need to do. However as an interim, if I cut out the entire document and paste it back it fixes all the names (although I would need to check after doing so that shapes have not had their positions thrown about).
3. The test I gave in comment 17 still suffers exactly the same problem in the new release as the 3.x, even after cutting the document out and pasting it back in to generate the new names and saving it as a new document then opening it, and carrying out the test of moving the arrow and doing Ctrl-Z. Comment 17 is here -
https://bugs.documentfoundation.org/show_bug.cgi?id=119111#c17
4. As a beta I'll give it a whirl and see if I can make any other observations.
Cheers, David
Comment 23 QA Administrators 2019-12-04 04:22:35 UTC Comment hidden (obsolete)
Comment 24 Dieter 2019-12-04 08:52:09 UTC
(In reply to DM from comment #17)
> On p3, move the arrow under "Long Awns" to be over the picture on its left
> (i.e. move it to be under "Flowerhead reaches upper leaf base" then click
> Ctrl-Z to undo the act. You'll see not only does it move back, but a
> completely random item from elsewhere in the document jumps there too. This
> is quite a common occurrence.

I confirm it with the provided steps and

Version: 6.4.0.0.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded

Shape "Shiny Leaves" jumps from page 1 to page 3.
Comment 25 Dieter 2019-12-04 09:13:30 UTC
Out of topic: It's not possible to change name of a shape; see bug 96405
Comment 26 DM 2019-12-04 11:26:16 UTC
Created attachment 156289 [details]
Cut-Doc-and-Repaste to give shapes unique names issue

As a method to rename shapes to unique names, I've just tried opening the attached document, highlighted its contents (Ctrl-A) cut it all out (Ctrl-X) and repasted it back (Ctrl-V), and this disrupts the layout in a way that it shouldn't.
Since this is a rather simple document affected, I anticipate it could have much larger impacts on my other docs.

Version: 6.4.0.0.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 2; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-GB
Calc: threaded
Comment 27 Telesto 2020-05-01 20:09:04 UTC
(In reply to DM from comment #26)
> Created attachment 156289 [details]
> Cut-Doc-and-Repaste to give shapes unique names issue
> 
> As a method to rename shapes to unique names, I've just tried opening the
> attached document, highlighted its contents (Ctrl-A) cut it all out (Ctrl-X)
> and repasted it back (Ctrl-V), and this disrupts the layout in a way that it
> shouldn't.
> Since this is a rather simple document affected, I anticipate it could have
> much larger impacts on my other docs.
> 
> Version: 6.4.0.0.beta1 (x64)
> Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
> CPU threads: 2; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
> Locale: en-GB (en_GB); UI-Language: en-GB
> Calc: threaded

Working properly with (but not with 6.4.3.2) 
Version: 7.0.0.0.alpha0+ (x64)
Build ID: f845f74afaf087a46c82ee4209e29caca0980b71
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL