Bug Hunting Session
Bug 80849 - FILESAVE: Insert Image as Link broken (PNG)
Summary: FILESAVE: Insert Image as Link broken (PNG)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: All All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
: 81423 84630 (view as bug list)
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-07-03 12:57 UTC by nicotnc-gecko
Modified: 2015-12-17 10:39 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nicotnc-gecko 2014-07-03 12:57:30 UTC
After inserting images as "linked" (as a workaround tentative to bug #46447) and editing a bit the presentation, some images are no more displayed as they are looked for in the wrong path.

For example, content.xml before the issue:
<draw:image xlink:href="../images/2011-10-WallStreetJournal_AA_SW.PNG" [...]

Then:
<draw:image xlink:href="../images/2011-10-WallStreetJournal_AA_SW.PNG%3FrequestedName=2011-10-WallStreetJournal_AA_SW" [...]

This happened both with PNG and SVG images. I could not determine what precise action triggers the issue.

The bug could be related to #46447 where embedded images href becomes blank and the picture disappears from Pictures folder.
Comment 1 Cor Nouws 2014-07-05 22:08:51 UTC
thanks for reporting,
I can't confirm but trust you!
Cor
Comment 2 ign_christian 2014-07-18 10:28:10 UTC
I can confirm this bug with following test conditions:
- AutoRecovery (auto save) activated every 1 minute
- with a PNG file
*) But I guess this also happen with any auto-save intervals and any image file

Step to reproduce:
1. Create new presentation
2. Insert > Image > From File
3. Select an image file and tick "Insert as Link" in the bottom left > Open > Keep Link
4. Wait for at least 1 minute to let auto-save executed
5. Save as an ODP
6. Close & reopen the ODP file

Reproduced with LO 4.3.0.3, 4.3.0.1, 4.2.6.1, 4.2.5.2 - Ubuntu 12.04 x86

Not reproduced with LO 4.3.0.0.beta1, 4.2.4.2

Upping the Importance since AFAIK this is a quite common function and dataloss
Comment 3 ign_christian 2014-07-18 10:37:49 UTC
Problem not reproduced if file saved before auto save executed as observed in:
https://bugs.freedesktop.org/show_bug.cgi?id=81423#c1
Comment 4 marc.bristiel 2014-07-18 10:48:49 UTC
*** Bug 81423 has been marked as a duplicate of this bug. ***
Comment 5 ign_christian 2014-07-18 14:43:25 UTC
Looks like no problem with SVG image
Comment 6 marc.bristiel 2014-07-18 19:54:25 UTC
To get rid of any interference, I installed Debian 7 in a virtual machine, with only the main libreoffice archive (LibreOffice_4.2.5_Linux_x86_deb.tar.gz)

With default settings, I did :
1. Lauch Libreffice
2. Create a new presentation
2. Save the odp file by "save as ..."
3. Insert a picture "as a link" and, yes, keep the link.
4. Save the file.
5. Check content.xml and link
6. Move the picture a bit.
7. Save the odp file.
8. Check content.xml and link

No need to wait for automatic saving.

Now the results :

The bug appears at step 7.

* With a png file, the string beginning with "%3FrequestedName=" is added to the link, broking it.
* With a svg file, the bug is PRESENT, but different : in that case the linked svg file is incorporated in the Pictures directory in the odp file, as it would have been manually incorporated ... So the bug is hidden (but behavior is wrong).
Comment 7 ign_christian 2014-07-19 10:28:32 UTC
(In reply to comment #6)
> 6. Move the picture a bit.
Emh..looks more complex now. That action is subjective. I'll do testing again
Comment 8 ign_christian 2014-07-19 15:52:56 UTC
Ok I got it Marc. Nice steps.. :)
Tried again with reproducing steps in comment 6
- with x86 deb packages without desktop integration
- default profile (15 minutes autosave enabled by default)

Did those steps in comment 6 from step 3 - 8 (only 2x saving, after image inserted & after image moved)
With PNG files (tried several different PNG files from different locations)
-> Reproduced in 4.3.0.3, 4.2.6.1
-> Not reproduced in 4.2.4.2, 4.3.0.0.beta1

Seems we have 2 similar cases here with different triggers:
- Comment 2 -> execution of autosave, NO modification of image (in this case: image moved)
- Comment 6 -> NO execution of autosave, manual file saving required before image moved (after image inserted)
*) Both 2 cases confirmed regression against LO 4.2.4.2 and 4.3.0.0.beta1

Perhaps we need separate bug report for SVG images since it's different behavior from Marc observation.
Comment 9 ign_christian 2014-07-19 16:50:14 UTC
(In reply to comment #6)
> * With a png file, the string beginning with "%3FrequestedName=" is added to
> the link, broking it.
> * With a svg file, the bug is PRESENT, but different : in that case the
> linked svg file is incorporated in the Pictures directory in the odp file,
> as it would have been manually incorporated ... So the bug is hidden (but
> behavior is wrong).

Confirm that. If we do SVG insertion (as link), there is a tag like this in content.xml:

<draw:image xlink:href="Pictures/10000201000000F6000000F65107668F.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>

Looks like the SVG image embeded as a PNG. So the image still shown in the ODP even actual SVG link is broken with additional "%3FrequestedName=" in the link.

But if we do PNG insertion as link, that tag not exist.
Comment 10 marc.bristiel 2014-07-19 19:06:50 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > * With a png file, the string beginning with "%3FrequestedName=" is added to
> > the link, broking it.
> > * With a svg file, the bug is PRESENT, but different : in that case the
> > linked svg file is incorporated in the Pictures directory in the odp file,
> > as it would have been manually incorporated ... So the bug is hidden (but
> > behavior is wrong).
> 
> Confirm that. If we do SVG insertion (as link), there is a tag like this in
> content.xml:
> 
> <draw:image xlink:href="Pictures/10000201000000F6000000F65107668F.png"
> xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
> 
> Looks like the SVG image embeded as a PNG.

Yes, during the first saving, a png copy of the linked svg is made and included in the odp file.

> So the image still shown in the
> ODP even actual SVG link is broken with additional "%3FrequestedName=" in
> the link.

Yes.

> But if we do PNG insertion as link, that tag not exist.

Yes, that is what happens. And no copy is put in the odp file for a source png file.
Comment 11 marc.bristiel 2014-07-19 19:30:20 UTC
> Seems we have 2 similar cases here with different triggers:
> - Comment 2 -> execution of autosave, NO modification of image (in this
> case: image moved)
> - Comment 6 -> NO execution of autosave, manual file saving required before
> image moved (after image inserted)
> *) Both 2 cases confirmed regression against LO 4.2.4.2 and 4.3.0.0.beta1


Maybe this is enventually the same case. I did another experiment.

In the options, Libreoffice > General > Document Status, I ticked "Allow to save document even the document is not modified".

Afer linking the picture, this allowed me to save twice, without moving the picture between the two saving steps. The bug appeared at the second saving.

If we sum up, in all cases what is happening is :
1. We link a picture in the document
2. We make a first saving, in which the link is correct
3. We make a seconde saving, which breaks links with this %3FrequestedName=...
Comment 12 David Tardon 2014-07-24 07:57:21 UTC
I believe this has been fixed by commit fd641c7b23ce4205c29fc0c564b73336cb2cfb07. Could someone check with the latest daily build?
Comment 13 ign_christian 2014-07-25 09:45:27 UTC
(In reply to comment #12)
Unfortunately I still can't test since I haven't seen x86 deb package newer than 2014-07-22 in http://dev-builds.libreoffice.org/daily
Comment 14 ign_christian 2014-07-30 16:26:29 UTC
(In reply to comment #12)
> I believe this has been fixed by commit
> fd641c7b23ce4205c29fc0c564b73336cb2cfb07. Could someone check with the
> latest daily build?

Seems FIXED with that commit. Tried PNG and SVG insertion as link in Ubuntu 12.04 x86 with steps in comment 2 and comment 6, works correctly with:

Version: 4.3.1.0.0+
Build ID: ce65a47f6028879337e9e133053cc397b1b582bd
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:libreoffice-4-3, Time: 2014-07-30_10:54:10

Not yet tried 4.2.7.0.0+
Comment 15 marc.bristiel 2014-07-30 21:21:03 UTC
Tested with nighty build (libreoffice-4-2~2014-07-30_13.16.10_LibreOfficeDev_4.2.7.0.0_Linux_x86_deb.tar.gz)

THe bug is gone.

However, with rc2 4.2.6 (LibreOffice_4.2.6.2_Linux_x86_deb.tar.gz)the bug is still present.
I doubt it would be a good idea to release 4.2.6 with that bug ...
Comment 16 forum 2014-10-03 16:06:18 UTC
*** Bug 84630 has been marked as a duplicate of this bug. ***
Comment 17 TeslaZap 2015-05-19 14:35:02 UTC
I'm still affected by this bug on LibreOffice 4.4.3.2

What I'm trying to do is adding a picture in the header (not body). After I close the document and reopen it, it's gone.

It doesn't work neither linked nor embedded, i tried jpg and png formats.
Comment 18 V Stuart Foote 2015-05-19 14:50:28 UTC
(In reply to TeslaZap from comment #17)
> I'm still affected by this bug on LibreOffice 4.4.3.2
> 
> What I'm trying to do is adding a picture in the header (not body). After I
> close the document and reopen it, it's gone.
> 
> It doesn't work neither linked nor embedded, i tried jpg and png formats.

Completely different issue and code base. Open a new bug with complete steps to reproduce.
Comment 19 V Stuart Foote 2015-05-19 15:02:23 UTC
(In reply to V Stuart Foote from comment #18)
> (In reply to TeslaZap from comment #17)
> > I'm still affected by this bug on LibreOffice 4.4.3.2
> > 
> > What I'm trying to do is adding a picture in the header (not body). After I
> > close the document and reopen it, it's gone.
> > 
> > It doesn't work neither linked nor embedded, i tried jpg and png formats.
> 
> Completely different issue and code base. Open a new bug with complete steps
> to reproduce.

Actually, your issue would seem to be that of TDF bug 89245 -- FORMATTING, FILESAVE: Header and footer background images are not saved
Comment 20 Robinson Tryon (qubit) 2015-12-17 10:39:27 UTC
Migrating Whiteboard tags to Keywords: (BibisectRequest)
[NinjaEdit]