Created attachment 59613 [details]
OLE positioning bug
There is a presentation with embedded Writer object in the attachment. I work on several presentations with such OLE objects because Writer gives much more formatting options.
To see the bug:
1. Open attached document in Impress.
2. Double click the highlighted text in the notes (OLE object).
3. Click somewhere outside to finish "editing" of OLE object.
Expected: nothing changed.
Actually: the OLE object moves.
Reproduced in versions from 3.4.* up to 3.5.1 on Ubuntu 11.10 and Windows XP 32 bit. Thats why I still use LO 3.3.4.
Maybe this bug is connected with the bug 47773 but in my case the LO 3.3.4 works correctly.
*** This bug has been marked as a duplicate of bug 51508 ***
For me this one is already [Reproducible] with attached sample and "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit). So I doubt that the problem has to do with Version.
[Reproducible] with "LibreOffice 188.8.131.52 English UI/ German Locale [Build-ID: 27122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit)
Because I can't erproduce Bug 51508 184.108.40.206 I doubt that these 2 really are Identical, remove DUPlication until final clarification
Your OS is?
As I said in first comment I reproduced this bug in versions from 3.4.* up to 3.5.1 on Ubuntu 11.10 and Windows XP (32-bit).
Recently I have reproduced it in 220.127.116.11 release (English UI) on Windows XP (32-bit).
I've found out that this bug is not about Impress only but also about Draw. Writer OLE object in Impress and Draw documents changes its position after editing.
Tested with LibO 18.104.22.168 @ WinXP32
Have tried to attach a Draw document with embedded Writer OLE object but got message "The file you are trying to attach is empty, does not exist, or you don't have permission to read it".
My additional comments to the first 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 (just open OLE and close it) and the container will match the text again.
Tested in Calc and saw the same (LibO 22.214.171.124 @ WinXP32)
So, tested components are: Impress, Calc, Draw. I bet all the components. If you have a file with non-damaged Writer OLE object and have edited this object you damage it.
Created attachment 64699 [details]
Calc document with non-damaged Writer OLE object created with LibO 126.96.36.199
Created attachment 64700 [details]
Draw document with non-damaged Writer OLE object created with LibO 188.8.131.52
Checked 184.108.40.206. No changes. Are there any news?
Maybe there are plans to reed off this buggy feature at all?
Oh my God! I became buggy myself at night when I was writing previous comment. I meant "to get rid of this feature". Because It's impossible to use it.
I have checked 3.5.7 and 3.6.4. It still doesn't work.
How to get that guy who made this regression?
Have changed version in description back to 3.4 because this issue was created in that version.
> How to get that guy who made this regression ?
If it reproduces on Linux, a user should be able to bibisect the problem down to a handful of commits - which really helps development: can you poke in the wiki for how to do that ?
(In reply to comment #12)
> If it reproduces on Linux, a user should be able to bibisect the problem
> down to a handful of commits - which really helps development: can you poke
> in the wiki for how to do that ?
Sorry, I don't understand what you are asking about. Even askoxford doesn't know the word "bibisect". The problem reproduces on different OS. So what can I do except of digging code?
> Sorry, I don't understand what you are asking about. Even askoxford doesn't
> know the word "bibisect". The problem reproduces on different OS. So what
> can I do except of digging code?
It does indeed look like an odd word ;-) Perhaps my google is customised for me too much somehow, but anyhow - putting 'bibisect' there gives me a #1 hit of:
Quite a big download is required, but then hopefully with only a dozen tests we can get very close to the one patch out of tens of thousands that causes the issue - which makes it immeasureably easier to fix (normally).
(In reply to comment #14)
Ok, I see. So it's a kind of digging. I love it but need time to do. Maybe I can do it on the holidays.
I take this one for further research, I am pretty sure that I already have seen bug reports concerning similar effects in bugzilla here. I will join related reports and I also will prompt the bibisecting, currently no more info required.
of course, it would be great if you could do the bibisecting. But for non-geeks it's a challenge, I think you should ask for assistance on the qa mailing list. And may be this one is a DUP of an other report, so I recommend to wait until you see my results here in the report (beginning of next week).
Thank you! I will be waiting for news from you.
I can reproduce reporter's problem with his sample document "Writer-OLE-created-with-3.3.4.ods" and a similar one created with Server Installation of "LibreOffice 3.3.3 German UI/Locale [OOO330m19 (Build:301) tag libreoffice-220.127.116.11] on German WIN7 Home Premium (64bit):
Opening such a document with Server Installation of "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) (or later) a double click on the Writer OLE object will shift the OLE object contents 20mm to the right and 20mm to the bottom
This is a Page border compatibility problem. In LibO 3.3.3 and in LibO 3.4.5 for the OLE object men 'Format -> Page - Borders' shows 20mm all around.
The difference is that in 3.3 that "page border" is outside the visible area of object, the contents starts directly at the top left border of the visible area of the object.
The same document opened with 3.4.5 after doubleclick on object (and left it again): Now the "page border" is part of the visible area, what shifts the "text down and to the right. Changing page borders to "0" at least heals the "shift right / down" problem, the first "text" now again appears at cell D6. The increased visible area might be a result of the page border issue, I would like to ignore that problem here for now.
Bug in 3.3. or 3.4, that's the question here.
ODF validators rate reporter's document as Invalid, see attached results.
Can you please check or should we forward this one to Michael Stahl?
Created attachment 71539 [details]
ODF validation results
I remember other similar issues what might be related, I will check that later
AOOo 3.4.1 shows the same problem as LibO 3.4 and later, “Lotus Symphony Release 3.0.1 Revision 20120110.2000” on German WIN7 Home Premium (64bit) does not show that problem. What ever that might mean.
Created attachment 71546 [details]
Draw document with Writer OLE object created with LibO 3.6
Maybe there was a bug until 3.4 but LibO 3.3.4 just _works_. I have attached a Draw document created with LibO 3.6. Try it. It's just incapable to manage with Writer OLE objects.
confirming it on LibO 4.0.4 and 4.1.0 final releases.
moving it to mab4.0 because 3.6 has reached EOL so we are in the process of closing the meta bug.
(This is an automated message.)
Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Moving to mab4.2 because bug confirmed is still here in 18.104.22.168 and 4.1 reached EOL (End Of Life)
bug persists under Win81 x64 using LibO 22.214.171.124 and 126.96.36.199.alpha0+
Build ID: 6b096f273ac9d7bbe93d2cb083958b3a04866d73
TinderBox: Win-x86@42, Branch:master, Time: 2014-12-04_22:57:23
moving this bug to mab4.3 list since 4.2.x is EOL
Too old for bibisect
Whiteboard -> notBibisectable
retested attachment 59613 [details] from comment 0
bug is still reproducible with LibO 188.8.131.52 and recent 184.108.40.206 alpha
however in 5.1.x the OLE object moves less than in 4.4. where the object almost goes out of the right margin
Migrating Whiteboard tags to Keywords: (notBibisectable)
Replacing keyword 'notBibisectable' by 'preBibisect' as this bug is outside the bibisect range
The bug is reproducible by LibreOffice 220.127.116.11 on Ubuntu 16.04.1
Build ID: 1:5.2.3~rc2-0ubuntu1~xenial1
CPU Threads: 4; OS Version: Linux 4.4; UI Render: default;
Locale: id-ID (en_US.UTF-8); Calc: CL
still present in LibO 18.104.22.168 and 22.214.171.124 master build from early january 2017.
still present in LibO 126.96.36.199 and recent 188.8.131.52 alpha daily build.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
This is still present
Build ID: ea9c13be02ba731074fa4207944ff7df40a0fb5c
CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx;
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2019-04-10_20:43:17
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Version: 184.108.40.206.alpha0+ (x64) / LibreOffice Community
Build ID: 005adbefc746f9024adcf572c287dc061acbcf00
CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
If I read this correctly, this is a bug that manifests itself if you have a document created in LO3.3 that uses OLE objects
As such, this can hardly have the "highest" priority any longer
E.g., the 3.6 test case does not shift the text when I open in 7.4 alpha, so it's been stable for almost a decade?
Setting as Medium - Minor as per my interpretation of the prioritization flow chart, but it could just as well be won't fix at this point?
Well, the OLE object does not move in the slide. That is the text in the OLE object which move. In other words, the window looking in the OLE object does not show the same area.
It would be useful to know how the document was created so that the OLE object does not show the top and left margins of the inserted text document.
Best regards. JBF