When the position has been lost rather than z-index the items often appear half off the right edge of the page.
d

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.

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

Please, do, otherwise it's very difficult for us to investigate this issue...

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

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

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

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.

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

(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.)

(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.

@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.

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).

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.

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.

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

Example added 'Move-Undo example of unrelated item jumping'

(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

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

(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.

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

(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.

Out of topic: It's not possible to change name of a shape; see bug 96405

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

(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

This problem seemed to have been solved in version 6, but it seems like it has resurfaced again. 

IF you have a picture or a photo, then use the line arrows to put label. One has to ARRANGE "BRING TO FRONT" the line , so that it will appear clearly where it is pointing on the picture. When you save the document and reopen it later, you will see that the line has reverted to BACK position. You have to "BRING TO FRONT" every time you open the document!

I'm fighting with this issue from ages :(
I don't know if it can help but I noticed that:

1. Using Linux version of LO the mess happens regularly (7.2.2.2), while on Windows 10 (can't recall LO version ATM) it doesn't. So I'm forced to finalize my manuals on Windows...

2. Analyzing the document (as FODT) I've noticed that z-index property didn't start from 0 (on a troubled document, don't know why: the order was 17, 0, 18, 19, 67, 68... even if my total count was 61!) and the sequence was not respected as it should have been. I didn't know that z-index is document-wide, but manually reorganizing all of them manually it finally worked out. (Meaning renumbering from 0 at the very first instance and so on until 61 for last one, in that case).

So it looks like a reorganize z-index feature should be needed. I imagine it ideally editable in the navigator: would probably be fantastic! But even without a UI would be dramatically useful.

Unfortunately my point 2 is wrong: even reorganizing all z-index manually it doesn't show correctly :(

It looked like it was working, because it fixed the image (with 8 callouts) I was referring to, but it messed up ALL the remaining images of the file, putting their callouts behind them.

I tried preparing an example, but with small files with few images it doesn't happen...

For reference, the Windows version saving my (working) life is:
Version: 7.0.5.2 (x64)
Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: it-IT (it_IT); UI: en-GB
Calc: threaded

This version respects the saved z-order. I write this because My understanding is that the Linux version does save correctly the z-index, but then doesn't respect it when reopening and rendering the file. But that's just my guess and I could be obviously wrong.

I don't see differences when I open the attached documents in LO and compare them with those in Edge Windows 11.
So, for me, this bug seems resolved.

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e9374f74385d7dfe77d1902d3d82af20143bc775
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: threaded

It still hides callouts behind pictures :(

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: it-IT (it_IT.UTF-8); UI: it-IT
Ubuntu package version: 4:7.6.2~rc1-0ubuntu0.20.04.1~lo1
Calc: threaded

I was(In reply to Gabriele Ponzo from comment #33)
> It still hides callouts behind pictures :(
> 
> Version: 7.6.2.1 (X86_64) / LibreOffice Community
> Build ID: 60(Build:1)
> CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
> Locale: it-IT (it_IT.UTF-8); UI: it-IT
> Ubuntu package version: 4:7.6.2~rc1-0ubuntu0.20.04.1~lo1
> Calc: threaded

And I did also rename all the (hundreds of) objects in my files.

Is it an ODF requirement to have a file-wide z-index?

Because I maybe wrong but can't see any reason for having its scope wider than the single page...

BTW I'm trying to create a macro (thanks to Rafael Lima) to automatically bring all the images in background and shapes in foreground before finalizing the document...

(In reply to Gabriele Ponzo from comment #35)
> Is it an ODF requirement to have a file-wide z-index?

Its specification is in https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#attribute-draw_z-index