Bug 42640 - FILEOPEN: Impress shows a picture different from the image stored in the file
Summary: FILEOPEN: Impress shows a picture different from the image stored in the file
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium normal
Assignee: Noel Power
URL:
Whiteboard: BSA
Keywords: regression
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-11-06 03:11 UTC by Jean-Baptiste Faure
Modified: 2011-12-23 17:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
ODP file with a CC logo in the slide master (46.60 KB, application/vnd.oasis.opendocument.presentation)
2011-11-06 03:11 UTC, Jean-Baptiste Faure
Details
Same problem with this file (13.56 KB, application/vnd.oasis.opendocument.text)
2011-11-06 12:18 UTC, Arnaud Versini
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Faure 2011-11-06 03:11:07 UTC
Created attachment 53215 [details]
ODP file with a CC logo in the slide master

Problem description: the problem occurs, for me, only with the master I compiled myself

Steps to reproduce:
1. open the following RTF file: https://bugs.freedesktop.org/attachment.cgi?id=52627
2. close this RTF file without exiting LibO
3. open the attached odp file

Current behavior: in the lower left corner you see the French Republic logo

Expected behavior: in the lower left corner you see the Creative Common logo as you see if you reload the odp file (File > Reload)

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111105 Firefox/10.0a1
Comment 1 Norbert Thiebaud 2011-11-06 04:06:28 UTC
I reproduced it on MacOSX with master at core:59829f4fd20f4238941123412423caa76e8be1a6

If I delete the temp files in the temp directory of LibreOffice and then re-open the odp, I get the correct graphic.
Comment 2 Arnaud Versini 2011-11-06 04:18:27 UTC
I confirm on linux with master on Ubuntu 11.10.
Comment 3 Jean-Baptiste Faure 2011-11-06 04:22:39 UTC
No problem if I convert the RTF file to ODF format and play the same scenario
with this new file instead of the RTF file.

Best regards. JBF
Comment 5 Jean-Baptiste Faure 2011-11-06 06:07:40 UTC
I confirm that this commit solves the problem.

Thank you for this quick fix. Closing the bug report.

Best regards. JBF
Comment 6 Jean-Baptiste Faure 2011-11-06 08:23:39 UTC
Sorry Miklos, if you don't close the RTF file before opening the ODP file, you see the wrong logo too. :-(

Best regards. JBF
Comment 7 Arnaud Versini 2011-11-06 12:18:49 UTC
Created attachment 53224 [details]
Same problem with this file
Comment 8 Arnaud Versini 2011-11-06 12:19:39 UTC
Same problem using the ODT file instead of the presentation.
Comment 9 Arnaud Versini 2011-11-06 12:35:11 UTC
There is an error message with --enable-debug :

Error: File /home/arnaud/core/sal/osl/all/debugbase.cxx, Line 125: unexpected number of 19SvxUnoTextRangeBase: 1
Comment 10 Rainer Bielefeld Retired 2011-11-06 21:56:25 UTC
[Reproducible] with parallel installation of MinGW Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  2ba5d12-e8c71c5-41e7bcd-4b83b90)] (daily/MinGW_cross-compilation2011-10-25_00.12.09)".

[Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]" (110909)

With both versions I only can open modele_dec_he_so.rtf one times. When I have closed it without leaving LibO, I can't open it a second time (from LibO file dialog), but I will get an error message:

Document file 'modele_dec_he_so.rtf' is locked for editing by: 
Unknown User
Open document read-only or open a copy of the document for editing

What ever that might mean concerning the reported problem.
Comment 11 Miklos Vajna 2011-11-07 01:04:54 UTC
Rainer,

That part is a feature, not a bug. :)
Comment 12 Rainer Bielefeld Retired 2011-11-07 03:15:11 UTC
@Miklos Vajna:
No feature (I have a little experience with LibO)! May be my wording was misinterpretative?

Steps to reproduce with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home
Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]" (110909)

1. Start soffice.exe
2. Open "modele_dec_he_so.rtf" from start center
   As expected it opens, ".~lock.modele_dec_he_so.rtf#" appears in
   document folder
3. Menu 'File -> Close'
    As expected document opens, lockfile disappears
4. Menu 'File -> Open - "modele_dec_he_so.rtf"
   Expected: can be opened
   Closed: Message as described.

The document remains locked, also can not be opened with another instance of LibO (3.4.4 RC2) until Libo Master will have been terminated.
Comment 13 Miklos Vajna 2011-11-07 04:04:33 UTC
Rainer,

Ah OK that is indeed a bug - I was not aware you closed the document between the two openings. ;)

Thanks.
Comment 14 Noel Power 2011-11-08 13:39:30 UTC
I'll take this for a while, started looking at it in any case, if I get nowhere I guess I'll put it back to the list.
Comment 15 Noel Power 2011-11-09 06:47:48 UTC
proposed fix here

http://cgit.freedesktop.org/libreoffice/core/commit/?id=02c6f5c74b346f1e3a095d99a36ece6b603bc26b

problem stemmed from the fact that properties were getting set before sdr object is created, this resulted in  SvxItemPropertySet::AddUsrAnyForID getting called. see http://opengrok.libreoffice.org/xref/core/svx/source/unodraw/unoshape.cxx#1807

Since the SvxItemPropertySet is shared between SvxShape instances the next opening detects these strange 'OwnUsrAny' things. Normally it would be expected trying to read these properties would clear them but the call sequence doesn't quite do that. Looking at the docx/xlsx import it seems that adding the shape to the drawpage ensures the sdr object exists and thus any property set attempts "do the right thing" 

Miklos can you have a look and make sure the patch is good for the import sequences you handle?

marking as fixed
Comment 16 Jean-Baptiste Faure 2011-11-09 07:11:07 UTC
Hi,

pulled -> compiled -> tested => correct picture is shown => seems to be fixed indeed.

Best regards. JBF