90811 – Images are not properly placed when viewing attached document

Bug 90811 - Images are not properly placed when viewing attached document

Summary: Images are not properly placed when viewing attached document

Status:	RESOLVED WORKSFORME

Alias:	None

Product:	LibreOffice
Classification:	Unclassified
Component:	Writer (show other bugs)
Version: (earliest affected)	4.2.0.4 release
Hardware:	All All

Importance:	high normal
Assignee:	Not Assigned

URL:
Whiteboard:
Keywords:	bibisected, regression

Depends on:
Blocks:	VCL-Scheduler
	Show dependency tree / graph

Reported:	2015-04-23 11:23 UTC by Pacho Ramos
Modified:	2021-05-16 08:33 UTC (History)
CC List:	8 users (show)

See Also:	86540
Crash report or crash signature:

Attachments
1.doc (410.50 KB, application/msword) 2015-04-23 11:23 UTC, Pacho Ramos	Details
1.png (220.35 KB, image/png) 2015-04-25 15:10 UTC, Pacho Ramos	Details
looks allright. (343.41 KB, image/jpeg) 2015-04-25 21:45 UTC, kba	Details
looks allright LO (365.28 KB, image/jpeg) 2015-04-25 22:19 UTC, kba	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Pacho Ramos 2015-04-23 11:23:59 UTC

Created attachment 115034 [details]
1.doc

For example the image from section 3 is displayed behind the text. On the other hand WPS Office and Google Docs are able to display it properly 

Thanks

Comment 1 Buovjaga 2015-04-25 15:01:00 UTC

I see no problems.

Please attach a screenshot showing the problem.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the screenshot.

Win 7 Pro 64-bit, Version: 4.4.3.1
Build ID: b2f347f2ac68821efc00b6f1793cda90af748118
Locale: fi_FI

Version: 5.0.0.0.alpha1+ (x64)
Build ID: f3375fa07f27bd2ade519af3c07d69040d10eaa9
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-22_23:38:50
Locale: fi_FI

Ubuntu 15.04 64-bit 
Version: 4.4.2.2
Build ID: 40m0(Build:2)
Locale: en_US

Comment 2 Pacho Ramos 2015-04-25 15:10:32 UTC

Created attachment 115089 [details]
1.png

screenshot

Comment 3 kba 2015-04-25 21:34:50 UTC

I was asked on libreoffice-qa to test it 

For me document is displayed correctly and all images are in correct places.

using:
Win7 64bit eng.
LO Wersja: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale: pl_PL

Comment 4 kba 2015-04-25 21:45:59 UTC

Created attachment 115099 [details]
looks allright.

Comment 5 Joel Madero 2015-04-25 21:46:22 UTC

I can confirm:

Ubuntu 15.04 x 64 w/ Unity
LibreOffice 4.4.2.2 release
LibreOffice 3.3 - can't confirm

This is a regression.


Marking as:

New - confirmed;
Normal - can prevent high quality/professional quality work and/or viewing;
High - regression

Note that this seems to only affect Linux which is weird.

Comment 6 Yousuf Philips (jay) (retired) 2015-04-25 22:15:29 UTC

Well the image is loaded with contour enabled and for some strange reason, linux decides to show the image fully transparent which doesnt happen on windows. It is a regression as it opens correctly in the 4.3 daily i have.

Version: 4.3.6.0.0+
Build ID: ddcf6367240d564e7daf4078e0a4caf0adde9043
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:libreoffice-4-3, Time: 2014-12-12_16:47:22

This reminds me of one of contour enabled when it shouldnt be bugs i filed (bug 86540).

Comment 7 kba 2015-04-25 22:19:02 UTC

Created attachment 115100 [details]
looks allright LO

Comment 8 raal 2015-11-16 14:03:52 UTC

Reproducible with Version: 4.4.0.0.alpha2+

Comment 9 raal 2015-11-20 19:55:46 UTC

I can reproduce with Version: Version: 5.1.0.0.alpha1+ (x64)
Build ID: 186f365a2c541c51e404b1fa819f35c9152adaf1
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-11-19_23:26:12

but not with Version: 5.1.0.0.alpha1+
Build ID: 32d4c03cba399ada807b8ec113a3928aa9e3ff7b
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-11-17_00:57:30

Seems to be windows only problem now.

Comment 10 Robinson Tryon (qubit) 2015-12-14 05:32:40 UTC Comment hidden (obsolete)

Migrating Whiteboard tags to Keywords: (bibisectRequest)
[NinjaEdit]

Comment 11 Aron Budea 2016-07-09 17:31:32 UTC Comment hidden (obsolete)

Still reproducible in master build / Windows 7 with attached document. Also tested, and reproduced with 5.1.4.2 / Ubuntu 16.04.

bibisect details:

# bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6
# good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474
git bisect start 'latest' 'oldest'
# bad: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81
git bisect bad 5d0dfb8e62ae61a240f8313c594d4560e7c8e048
# bad: [c0ef5c9ad28738878bb28206d62a57aa367cad92] source-hash-d47678c990681d0cfc7f2c843bb9aedaeb08511a
git bisect bad c0ef5c9ad28738878bb28206d62a57aa367cad92
# good: [652c8d1675dc8b174de907d4204dbc2ec98fe325] source-hash-0aa3dee5e88a1494a7a6a8401e084cbdb4324727
git bisect good 652c8d1675dc8b174de907d4204dbc2ec98fe325
# good: [89c2417b2972072396b05e705a2cadec46c269b1] source-hash-5ab1098d5fbc1ba092da73af2b92e5bcdd7a3f8d
git bisect good 89c2417b2972072396b05e705a2cadec46c269b1
# good: [5b1483b5c815fd009777fec213f964f5a37dc2ff] source-hash-be1bb7b1ccee28be616b89cc95e97d656e78bbe3
git bisect good 5b1483b5c815fd009777fec213f964f5a37dc2ff
# bad: [daf852f47d4f0d3e531138611c2d35d64a90460a] source-hash-fe9f8144c7a1a5e51544b4dacb8a2d7e70b321ee
git bisect bad daf852f47d4f0d3e531138611c2d35d64a90460a
# bad: [f817802ec63276a72a7711648ce471ca7ff7e45a] source-hash-bf640ba048704220292411e4f2bcc0d3c62caa32
git bisect bad f817802ec63276a72a7711648ce471ca7ff7e45a
# good: [258e084e9b9a18f5641f9d4df0b321467bec2560] source-hash-d718c1f65f850f7897b942c2e4415110132e51a5
git bisect good 258e084e9b9a18f5641f9d4df0b321467bec2560
# first bad commit: [f817802ec63276a72a7711648ce471ca7ff7e45a] source-hash-bf640ba048704220292411e4f2bcc0d3c62caa32
 f817802ec63276a72a7711648ce471ca7ff7e45a is the first bad commit
commit f817802ec63276a72a7711648ce471ca7ff7e45a
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun Oct 19 00:23:22 2014 +0000

    source-hash-bf640ba048704220292411e4f2bcc0d3c62caa32
    
    commit bf640ba048704220292411e4f2bcc0d3c62caa32
    Author:     Stephan Bergmann <sbergman@redhat.com>
    AuthorDate: Thu Aug 21 17:44:40 2014 +0200
    Commit:     Stephan Bergmann <sbergman@redhat.com>
    CommitDate: Thu Aug 21 17:44:40 2014 +0200
    
        Fix *_component_getFactory function type
    
        Change-Id: Id16c653554f5573dc862e0798747b7337ff74d44

Comment 12 Aron Budea 2016-07-15 23:33:59 UTC

Three different bibisects with the 44max repo gave three different results. I assume if I make a mistake during bibisect, the steps would stop alternating between good/bad results altogether. That wasn't the case, there were always good/bad steps mixed, and the final commit found were things like coverity fixes, obviously unrelated.

Today I tried again, first step with cleared user cache gave bad result. Restarting LO after clearning cache again gave good result. I give up.
This bug might not be bibisectable, but I'm confused, so not saying anything conclusive. Also, the bug certainly seems to have become deterministical since then.

Comment 13 Yousuf Philips (jay) (retired) 2016-08-03 05:26:04 UTC

Bug is there on linux on master.

@raal, @xisco: can you guys check if you can bibisect this.

Version: 5.3.0.0.alpha0+
Build ID: 389b08190092f9a9103b3ac098994ec83b2d0bfa
CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-08-02_01:46:19
Locale: en-US (en_US.UTF-8); Calc: group

Comment 14 Xisco Faulí 2016-08-10 13:28:50 UTC

So far, I've been able to reproduce the issue with

Version: 4.3.0.0.alpha0+
Build ID: 3e7b69ae3504a32e142cbf538b751ade38fbfdba

but I still need to bibisect it with older builds.

Note: THIS ISSUE IS NOT SYSTEMATIC, thus it's not always reproducible. It's convenient to test it several times before concluding that it's not reproducible.

Comment 15 Xisco Faulí 2016-08-10 17:09:50 UTC

I can also reproduce it with

Version: 4.2.0.0.alpha0+
Build ID: 6e2ff4edb2aae441142280ef31286f4627347fb

Comment 16 Rostislav 'R.Yu.' Okulov 2016-10-17 18:55:37 UTC

 a3ac6ea477851480773fbb341fe6032cdf54ffe2 is the first bad commit
commit a3ac6ea477851480773fbb341fe6032cdf54ffe2
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Thu May 28 21:55:27 2015 +0800

    source-hash-0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
    
    commit 0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Tue May 13 20:39:53 2014 +0100
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Thu May 15 10:21:22 2014 +0100
    
        coverity#440876 Dereference null return value
    
        Change-Id: I7d00c3a3c1a12176e4b1ab74712aabeb2f1cf90e

:040000 040000 0682b42f48cf36dd929c520d24dc75a34b0300be 3f6d678f09bb3dc143caa6dd1928eabb65137382 M      opt



# bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64
# good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3
git bisect start 'latest' 'oldest'
# good: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f
git bisect good e289d9d328719fd70e9a2680fd0e4f586a97b3be
# good: [3e807472869ed7d72b026c12cd1e7c3cb990591f] source-hash-6390dd9777ff63ca75a088e56dd444a355439343
git bisect good 3e807472869ed7d72b026c12cd1e7c3cb990591f
# good: [badf3854a52f4805b58cb5d82c7f5008bb08d70e] source-hash-a911f866623db7a03b12f0143df8d54a95805581
git bisect good badf3854a52f4805b58cb5d82c7f5008bb08d70e
# good: [f68a3ffd75febb1be3f68d578bba9d65d43317e6] source-hash-34509a0805d408cd45c1b95f5afdafdc46c1501e
git bisect good f68a3ffd75febb1be3f68d578bba9d65d43317e6
# bad: [979807345606fff7e86f0607844bf5b46d889320] source-hash-a4f32eec653596483088c6e5aa37de031278d74c
git bisect bad 979807345606fff7e86f0607844bf5b46d889320
# good: [cd4e6ec28a8fcaf62ac4fae7d995315a5c59adcf] source-hash-fd5ce1335d1bbc7d0bd86e7f3328461af2367711
git bisect good cd4e6ec28a8fcaf62ac4fae7d995315a5c59adcf
# good: [4e74e9b46ba1947edc7fdf111fde1590ecd44182] source-hash-95bb3305ca1ebfdd99a201d1d3234c820268af19
git bisect good 4e74e9b46ba1947edc7fdf111fde1590ecd44182
# good: [733067fa5090713c9d7c89e88ad83bd67e279999] source-hash-7249ba6877ef687fd787375e18678c5f1f417a49
git bisect good 733067fa5090713c9d7c89e88ad83bd67e279999
# good: [3a3d009b641c75444a138ab16902445b9b8d920e] source-hash-282b0123a34b978ea221d88ac668ed0c4423f801
git bisect good 3a3d009b641c75444a138ab16902445b9b8d920e
# bad: [a3ac6ea477851480773fbb341fe6032cdf54ffe2] source-hash-0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
git bisect bad a3ac6ea477851480773fbb341fe6032cdf54ffe2
# good: [459d262fd64966f584f0657af2ab809035bd7482] source-hash-7e586cee33a978703bfc11571adc3cf68a4d714e
git bisect good 459d262fd64966f584f0657af2ab809035bd7482
# good: [184950fd7d97f0da6bca22d700adc04b62723cee] source-hash-1dd9c63a3520078e81a4a207060890e23591a41e
git bisect good 184950fd7d97f0da6bca22d700adc04b62723cee
# good: [dc1087bda9fee60e5ae3067e99a825185fd168d8] source-hash-6d1ee0f6fb40cbdac48abde99d4d41b50c4f0fcf
git bisect good dc1087bda9fee60e5ae3067e99a825185fd168d8
# good: [a842f463ec65bf8c4e0d5e8c0e93a55c332178f3] source-hash-9831dc20ab35bfe962f35d9033a3812be745a958
git bisect good a842f463ec65bf8c4e0d5e8c0e93a55c332178f3
# first bad commit: [a3ac6ea477851480773fbb341fe6032cdf54ffe2] source-hash-0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898

Comment 17 raal 2016-10-17 19:39:01 UTC

(In reply to Rostislav 'R.Yu.' Okulov from comment #16)
> a3ac6ea477851480773fbb341fe6032cdf54ffe2 is the first bad commit
> commit a3ac6ea477851480773fbb341fe6032cdf54ffe2
> Author: Matthew Francis <mjay.francis@gmail.com>
> Date:   Thu May 28 21:55:27 2015 +0800
> 
>     source-hash-0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
>     
>     commit 0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
>     Author:     Caolán McNamara <caolanm@redhat.com>
>     AuthorDate: Tue May 13 20:39:53 2014 +0100
>     Commit:     Caolán McNamara <caolanm@redhat.com>
>     CommitDate: Thu May 15 10:21:22 2014 +0100
>     
>         coverity#440876 Dereference null return value
>     
>         Change-Id: I7d00c3a3c1a12176e4b1ab74712aabeb2f1cf90e
> 
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks

Comment 18 Xisco Faulí 2016-10-17 21:14:37 UTC

(In reply to raal from comment #17)
> (In reply to Rostislav 'R.Yu.' Okulov from comment #16)
> > a3ac6ea477851480773fbb341fe6032cdf54ffe2 is the first bad commit
> > commit a3ac6ea477851480773fbb341fe6032cdf54ffe2
> > Author: Matthew Francis <mjay.francis@gmail.com>
> > Date:   Thu May 28 21:55:27 2015 +0800
> > 
> >     source-hash-0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
> >     
> >     commit 0ac3a94c9f7bffe27ec1e07c4cc73cf2425b3898
> >     Author:     Caolán McNamara <caolanm@redhat.com>
> >     AuthorDate: Tue May 13 20:39:53 2014 +0100
> >     Commit:     Caolán McNamara <caolanm@redhat.com>
> >     CommitDate: Thu May 15 10:21:22 2014 +0100
> >     
> >         coverity#440876 Dereference null return value
> >     
> >         Change-Id: I7d00c3a3c1a12176e4b1ab74712aabeb2f1cf90e
> > 
> This seems to have begun at the below commit.
> Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
> Thanks

Hi raal, Rostislav,
Thank you for the comments but I'm pretty sure that is not the problematic commit.
First, that commit is in framework, which is not related to the .doc filter, and second, as I said in comment 14, the problem isn't systematic, so it needs to be tested several times in order to conclude whether it's reproducible. I could reproduce it in 4.2.0.0.alpha1+ (around 2013-11-21 ) and that commit is from 2014-05-13

Comment 19 Rostislav 'R.Yu.' Okulov 2016-10-18 04:26:50 UTC

(In reply to Xisco Faulí from comment #18)

> Hi raal, Rostislav,
> Thank you for the comments but I'm pretty sure that is not the problematic
> commit.
> First, that commit is in framework, which is not related to the .doc filter,
> and second, as I said in comment 14, the problem isn't systematic, so it
> needs to be tested several times in order to conclude whether it's
> reproducible. I could reproduce it in 4.2.0.0.alpha1+ (around 2013-11-21 )
> and that commit is from 2014-05-13

I do not understand anything now. Take a look at bug https://bugs.documentfoundation.org/show_bug.cgi?id=87921

it was bibisected by me. Next Matthew Francis bisected it! Did you see? Bibisected or bisected. And yes commit founded my bibisection is not the last one.

Comment 20 Caolán McNamara 2016-10-18 08:45:04 UTC

My bibisect suggests it went wrong in

git log 825098182227fdca958f84235d278c41b2b942ab..333f8a76341f5b4921e89012d133007503e49612

but a lot of those commits are related to idles and timers which makes me wonder if this is something fragile which sort of works sometimes and sometimes not in variable way as code gets tweaked

Comment 21 QA Administrators 2017-11-14 08:57:58 UTC Comment hidden (obsolete)

** 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!

Warm Regards,
QA Team

MassPing-UntouchedBug

Comment 22 Karsten 2019-01-16 11:12:25 UTC Comment hidden (obsolete)

A general discussion is needed: https://bugs.documentfoundation.org/show_bug.cgi?id=122730

Comment 23 QA Administrators 2021-05-16 03:45:30 UTC Comment hidden (obsolete)

Dear Pacho Ramos,