*** Bug 48409 has been marked as a duplicate of this bug. ***

I have tested in 3.5.5rc3 and 3.6.0.0.beta3 and saw the same issue.

Based on kitaets comment in 48409 it works fine in ver 3.3.4, hence 'regression' keyword.

Verified with LibreOffice 3.5.3.2 350m1(Build:2)

In 3.5.5 release (3.5.5.3) still doesn't work. Still no one can use Writer OLE object in presentation.

I have changed the summary and importance after I've tried to insert Writer OLE object to drawing document. There is the same bug. I've also tried to insert one to spreadsheet and it was also ridiculous but slightly another way. 
Sorry if I done something wrong, the importance field is not described on help page. But if this bug completely stops you from using the release, it has the highest importance imho.

I can't reproduce the problem with "LibreOffice  3.5.5.3  English UI/ German Locale  [Build-ID: 27122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit) and an own sample created with 3.4.5. Control points kept "glued"

I will check Bug 48409, what seems to have a more useful test kit, soon. 

@Valek:
Please contribute information concerning your OS

@Valek, kitaets
Please test whether other Ole objects are affected the same way.

@kitaets
Due to my results in Bug 48409 I have the suspect that the very similar symptoms might have different roots. Did you submit this Bug with intention because you see indicatioons that the problem here might be different from Bug 48409?
Please attach a sample document.

Rainer,
linux x86 is here.

As far as I understood on a Russian linux community blog, kitaets created two bugs because he was not aware that both will end-up in the same bugzilla and he had no response for the 1st one created.
So, my understanding is that from his point of view it's two bugs opened for one problem. That's why I marked one of them as a duplicate.

kitaets, could you confirm what was your intention?

Created attachment 64200 [details]
Writer OLE object in LibO 3.5.5.3 Draw

LibreOffice 3.5.5.3 (Draw) English UI on English WinXP (32bit)

Please look at the new screenshot.
Spreadsheet and chart OLE objects are affected but another way: they change place if you change size. Tested with the same Draw@WinXP32.

@Rainer, Valek
Yes, I wrote on a Russian linux community blog about this bug.
At first I created report "Bug 48409" on this site (because I have several documents that I can't edit with new releases).
Several months later I saw that nothing changed and thought that this is not the right place for LibO bugs. Futhermore I noticed that it's impossible to create new OLE objects in new documents. So I created a new bugreport on official LibO site and was surprised finding out that it was created here.
I think that these bugs are the same bug because I can create and edit OLE objects with 3.3.4 and can not with newer releases.

@Rainer
Sorry, I haven't understood what sample document you need.

I've corrected the misprint in Summary field.

@Rainer
Is it correct that you set Component field to "Database"?

Has nothing to do with data base

I removed from MAB because it's not a good Idea to bore losts of developers with our discussion here.

May be I completely misunderstood the intended report. During my tests I found a horrible bunch of possible and real problems, we sill have to do some workout. 

Further discussion please based on attachment 59613 [details]!

@kitaets
Am I right that the original problem is as following:
0. Open attachment, check OLE object position and size:
   > x:20  y:141  w:170  h:143 (all: mm)  
1. double click the OLE Text object in attachment 59613 [details] for Bug 48409 
   > Edit mode
2. Click somewhere far away from Ole object
   Expected: all looks as in step 0
   Actual: Position and size of OLE text object still ist the same, but the
           focus on the text inside the object has moved. So now the text 
           is visible more to the bottom and right slide margin. Additional
           Effect:  The text within contour correctly shows formatting 
           "Background", but outside the contour only unformatted text is 
           visible

Concerning your question: A sample document is a document (here Drawing or Presentation) what other users can use to reproduce the problem. Your attachment "Writer OLE object in LibO 3.5.5.3 Draw " is a screenshot.

Created attachment 64222 [details]
ODP after described four steps

@Rainer

In last two hours I have done dozen tests, going crazy but don't now if this are two different bugs or not.
Sorry I was wrong about other OLE objects: they are not affected. I saw some issues but there are other issues, not current bug(s). Really sorry for that. So my bugs are about Writer OLE object in presentation and drawing documents.

You are completely right in description of the original problem. So this problem is about shifting the content of Writer OLE object. And this problem is 100% regression.
My additional comments to your description:
a) If you have created OLE object in older version of LibO (3.3.4) you can edit your document in new releases and save it and your object will stay "non-corrupted". But if you try to edit your OLE object it becomes corrupted.
b) If you create a new OLE object in new release it becomes corrupted "from the birth".
c) You can "repair" corrupted OLE object with older release and the container will match the text again.

Another problem is about resizing Writer OLE object. Try to resize OLE object in new attach to make it match the snaplines. You can increase the width but not reduce. Also you will see some visual issues. It works better in 3.3.4 (but not perfect) so I think this is regression too.

And the problem described here in Bug 51508 is a combination of #1 and #2. You can see this problem just when you are creating new Writer OLE object and trying to resize it before you finish the creation. When you finish the creation you will see that your object has wrong dimensions. All you need to reproduce is a blank document. That's why I gave screenshots. You can see the new-created Writer OLE object with wrong dimensions and positioning in the new attach.

Why status "NEEDINFO"?

(In reply to comment #18)
> Why status "NEEDINFO"?

I believe the reason is that Rainer is busy at the moment. He changed the status and asked me for additional information, so I've given it. Maybe I can do something?

Changing component to graphics stack, this has nothing to do with the database, although it could probably also go under framework.

Alex

We already have at least 1 other report to a similar problem, as far as I remember this is a very old problem inherited from OOo, but during a first attempt I was not able to find the Bug.

I will get my research here finished until weekend, and indeed, on more info from reporter required

@ Rainer

1) Why UNCONFIRMED again? Valek has confirmed the bug in Comment 4.

2) What do you mean "more info from reporter required"? What do you need me to do?

3) Summary does not clearly describe the bug:
a) it's not only about Impress, it's about Draw too;
b) it's not about OLE object itself but about the content of the OLE object.

@ Rainer

Sorry, I confused 3a (it's not only about Impress...) with another bug.

@kitaets: 
In Comment 21 please strike "on", insert "no". 

Please read
<https://wiki.documentfoundation.org/BugTriage#Process>  item 5

@Rainer

Ok, I will wait for the results of your research.

> ...as far as I remember this is a very old problem inherited from OOo.
Not so old. I use LibO 3.3.4.1 - the last release without this bug.

Just checked 3.5.6.2. No changes. Are there any news?

If you all agree I would mark this one as DUP of bug 51119.

(In reply to comment #27)
> If you all agree I would mark this one as DUP of bug 51119.

_May_be_ this is about the same bug. But in bug 51119 they say about the pasting and this description is about creating and editing. So we don't really know if these are the same bug or not.

I can confirm mentioned behavior, so I'm going to mark this one as NEW. Bug 51119 looks indeed like a dupe. It contains bugs of this one, but it also lists other bugs (like the gray unnecessary border). Therefore I think marking this bug as NEW is the only correct way to go.

Kind regards,
Joren

Can you please test this with the newest version of LibreOffice Fresh?

(In reply to comment #30)
> Can you please test this with the newest version of LibreOffice Fresh?

Philipp, I've been waiting for TWO years. It is a shameful bug that was inserted in LibO by someone and didn't allow you to use OLE at all, but who on earth cared about it?
I just need to WORK, to edit my documents. So I've done a LOT of work to get rid of OLE in my documents. Time wasting but I had no another option. Now I don't care about this bug too.
Sorry, thank you.

I can still reproduce this with 4.3.2.2 on Windows 7.

It only affects Writer (text) OLE objects, tested in Draw and Writer. In Draw you even see artifacts, just when moving the OLE object around.

One bug should contain one issue. Restating this bug for the first issue mentioned on comment 0. (See bug 88808 and bug 88809 for issues (2) and (3))

Issue (1), that the aspect ratio of an OLE text object in Draw is changed when resizing it while it is open for editing, will continue to be dealt with on this bug.

The issue does appear to be a regression, and probably introduced, or at least worsened during the range of the bibisect 43all repository. Frustratingly though, the exact point of origin defies identification. There is at least a range towards the beginning in which it appears to occur only intermittently.

-> Replaced Whiteboard:bibisectRequest with notBibisectable
-> Updated Summary to reflect the issue dealt with on this bug

Changing version back to the earliest version affected.

NOT reproduced with:
- LibreOffice 3.3.4 
OOO330m19 (Build:401)
tag libreoffice-3.3.4.1

Confirmed with:
- LibreOffice 3.4.0 
OOO340m1 (Build:11
- Version: 5.3.4.2 (x64)
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Windows 6.1; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR); Calc: group
- Version: 5.4.0.3
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
Threads CPU : 4; OS : Windows 6.1; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: CL
- Version: 6.0.0.0.alpha0+
Build ID: 18f80da7a689ab962735c0f657497b8f1ed4d606
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-07-28_05:19:39
Locale: fr-FR (fr_FR); Calc: CL

I think that a part of the problem come from the fact that you try to fit a A4 size page (OLE object) in a smaller rectangle (in Draw). In your OLE object, if you resize your page to fit the size of the rectangle, the behavior looks much less buggy (even if it is not perfect).

(In reply to Laurent BP from comment #41)
It shouldn't be "less buggy". It should be NOT buggy at all. 
I don't try to fit the A4 size page. I try to fit fully formatted text into the rectangle. The text in the rectangle. With no additional tricks.
It used to work until version 3.4.0. Then someone corrupted this function. And it is not usable till this very moment. 
This bug have brought a lot of pain to me. I had documents with the OLEs, and I had spent hours to fix them.

I do not reproduce the problem with Version: 7.3.2.0.0+ / LibreOffice Community
Build ID: 9e32472d623998a1beaaf69342c53d1be5d1732f
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Ubuntu_20.04_x86-64
Calc: threaded

The bug description seems to me incomplete in step 2. Indeed nothing is said about the layout of the text document page. The area of the OLE object that is shown is the top left rectangle. So in order to keep the text close to the rectangle borders, it is necessary to set the margins to 0 and to define the page width equal to the width of the rectangle.

Closing as WorksForMe.

Best regards. JBF