Bug 48409 - FILEOPEN LibO 3.3 documents shows Writer OLE object contents shifted right / down in object after edit of object because of page border issue
Summary: FILEOPEN LibO 3.3 documents shows Writer OLE object contents shifted right / ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86 (IA32) All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: Confirmed:4.2.0.2:OSX
Keywords: preBibisect, regression
Depends on:
Blocks: OLE-Object-Interoperability
  Show dependency treegraph
 
Reported: 2012-04-06 20:44 UTC by kitaets
Modified: 2024-02-23 03:14 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
OLE positioning bug (22.30 KB, application/vnd.oasis.opendocument.presentation)
2012-04-06 20:44 UTC, kitaets
Details
Calc document with non-damaged Writer OLE object created with LibO 3.3.4.1 (14.09 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-07-26 08:15 UTC, kitaets
Details
Draw document with non-damaged Writer OLE object created with LibO 3.3.4.1 (16.28 KB, application/vnd.oasis.opendocument.graphics)
2012-07-26 08:23 UTC, kitaets
Details
ODF validation results (15.44 KB, application/vnd.oasis.opendocument.text)
2012-12-15 09:35 UTC, Rainer Bielefeld Retired
Details
Draw document with Writer OLE object created with LibO 3.6 (20.46 KB, application/vnd.oasis.opendocument.presentation)
2012-12-15 12:06 UTC, kitaets
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kitaets 2012-04-06 20:44:55 UTC
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.
Comment 1 Valek Filippov 2012-07-05 16:47:29 UTC

*** This bug has been marked as a duplicate of bug 51508 ***
Comment 2 Rainer Bielefeld Retired 2012-07-14 11:36:06 UTC
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  3.5.5.3  English UI/ German Locale  [Build-ID: 27122e39-92ed229-498d286-15e43b4-d70da21] on German WIN7 Home Premium (64bit)


Because I can't erproduce Bug 51508 3.5.5.3 I doubt that these 2 really are Identical, remove DUPlication until final clarification

@kitaets, @Valek:
Your OS is?
Comment 3 kitaets 2012-07-14 11:57:56 UTC
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 3.5.5.3 release (English UI) on Windows XP (32-bit).
Comment 4 kitaets 2012-07-25 20:53:18 UTC
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 3.5.5.3 @ 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".
Comment 5 kitaets 2012-07-25 20:59:20 UTC
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.
Comment 6 kitaets 2012-07-26 07:44:13 UTC
Tested in Calc and saw the same (LibO 3.5.5.3 @ 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.
Comment 7 kitaets 2012-07-26 08:15:12 UTC
Created attachment 64699 [details]
Calc document with non-damaged Writer OLE object created with LibO 3.3.4.1
Comment 8 kitaets 2012-07-26 08:23:31 UTC
Created attachment 64700 [details]
Draw document with non-damaged Writer OLE object created with LibO 3.3.4.1
Comment 9 kitaets 2012-10-02 21:05:26 UTC
Checked 3.5.6.2. No changes. Are there any news?
Maybe there are plans to reed off this buggy feature at all?
Comment 10 kitaets 2012-10-03 04:35:59 UTC
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.
Comment 11 kitaets 2012-12-13 19:34:03 UTC
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.
Comment 12 Michael Meeks 2012-12-14 09:26:52 UTC
> 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 ?
Comment 13 kitaets 2012-12-14 10:19:02 UTC
(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?
Comment 14 Michael Meeks 2012-12-14 10:30:59 UTC
> 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:

http://wiki.documentfoundation.org/QA/HowToBibisect

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

Thanks !
Comment 15 kitaets 2012-12-14 11:10:17 UTC
(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.
Comment 16 Rainer Bielefeld Retired 2012-12-14 11:58:16 UTC
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.

@kitaets:
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).
Comment 17 kitaets 2012-12-14 12:19:19 UTC
@ Rainer
Thank you! I will be waiting for news from you.
Comment 18 Rainer Bielefeld Retired 2012-12-15 09:30:03 UTC
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-3.3.3.1] 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.

@Michel Meeks:
Can you please check or should we forward this one to Michael Stahl?
Comment 19 Rainer Bielefeld Retired 2012-12-15 09:35:31 UTC
Created attachment 71539 [details]
ODF validation results

I remember other similar issues what might be related, I will check that later
Comment 20 Rainer Bielefeld Retired 2012-12-15 11:32:52 UTC
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.
Comment 21 kitaets 2012-12-15 12:06:28 UTC
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.
Comment 22 tommy27 2013-07-31 20:14:32 UTC
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.
Comment 23 Björn Michaelsen 2014-01-17 09:58:28 UTC Comment hidden (obsolete)
Comment 24 retired 2014-01-17 12:24:13 UTC
Confirmed:4.2.0.2:OSX
Comment 25 Stéphane Guillou (stragu) 2014-02-12 08:11:31 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 26 tommy27 2014-05-02 14:05:57 UTC
Moving to mab4.2 because bug confirmed is still here in 4.2.3.3 and 4.1 reached EOL (End Of Life)
Comment 27 tommy27 2014-12-07 18:41:17 UTC
bug persists under Win81 x64 using LibO 4.3.4.1 and 4.5.0.0.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
Comment 28 Robinson Tryon (qubit) 2015-03-05 18:34:07 UTC
Too old for bibisect
Whiteboard -> notBibisectable
Comment 29 tommy27 2015-06-16 19:46:36 UTC
retested attachment 59613 [details] from comment 0

bug is still reproducible with LibO 4.4.3.2 and recent 5.1.0.0 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
Comment 30 Robinson Tryon (qubit) 2015-12-14 05:51:15 UTC Comment hidden (obsolete)
Comment 31 Xisco Faulí 2016-09-14 22:14:45 UTC
Replacing keyword 'notBibisectable' by 'preBibisect' as this bug is outside the bibisect range
Comment 32 Rizal Muttaqin 2016-11-21 00:02:30 UTC
The bug is reproducible by LibreOffice 5.2.3.2 on Ubuntu 16.04.1

Version: 5.2.3.2
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
Comment 33 tommy27 2017-02-18 14:21:14 UTC
still present in LibO 5.2.5.1 and 5.4.0.0 master build from early january 2017.
Comment 34 tommy27 2017-07-23 07:51:52 UTC
still present in LibO 5.3.4.2 and recent 6.0.0.0 alpha daily build.
Comment 35 QA Administrators 2018-07-24 02:36:38 UTC Comment hidden (obsolete)
Comment 36 eisa01 2019-06-08 11:20:32 UTC
This is still present

Version: 6.3.0.0.alpha0+
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
Calc: threaded
Comment 37 Buovjaga 2021-03-19 17:17:09 UTC
Still repro

Version: 7.2.0.0.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
Calc: threaded
Comment 38 ustrendingnews 2021-05-16 07:31:20 UTC Comment hidden (spam)
Comment 39 eisa01 2021-12-26 00:17:14 UTC
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?
Comment 40 Jean-Baptiste Faure 2022-02-22 09:38:06 UTC
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
Comment 41 QA Administrators 2024-02-23 03:14:54 UTC
Dear kitaets,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug