Bug Hunting Session
Bug 113962 - Insert Image instances wrong image in drawing (.jpg with .gif extension, GTK3-only)
Summary: Insert Image instances wrong image in drawing (.jpg with .gif extension, GTK3...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.3.7.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.0.0
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2017-11-21 03:19 UTC by James D Howard
Modified: 2018-02-18 11:16 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example reproducer (.tgz) (59.07 KB, application/x-gzip)
2017-11-22 04:22 UTC, James D Howard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James D Howard 2017-11-21 03:19:41 UTC
Description:
An existing .odg drawingis being edited.  With nothing selected, [Insert]->[Image...] dialog box is used, and a .GIF file is selected.  Upon [ Open ], an image is added to the drawing, but it is NOT the image chosen - it is another image already inserted into the drawing.  The previously inserted image is a .JPG (if that has any bearing on the problem.)

After [Edit]->[Undo Insert ...], I used GIMP to read the .GIF file, [Export] it as a .JPG, and re-do the [Insert]->[Image...] -- selecting the just created .JPG.  This time the expected image is inserted.

Steps to Reproduce:
0. Existing drawing with several images placed; drawing opened
   for editing. Have a .GIF image in a file ready to be the
   target of an [Insert]->[Image...].  Nothing selected
1. Open file selection dialog box using [Insert]->[Image...], select
   your .GIF image
2. hit [ Open ]
3. A previously-used image is re-instantiated into the drawing, NOT
   the image in the selected .GIF

Actual Results:  
An additional placement of an image already in the drawing newly appears, and the image in the selected file is nowhere to be seen

Expected Results:
Image in the .GIF file should be placed on the drawing canvas, ready to be resized, moved, etc.


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: DrawingDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes

Version: 5.3.7.2.0+
Build ID: 5.3.7.2-1.fc26
CPU Threads: 8; OS Version: Linux 4.13; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36
Comment 1 Buovjaga 2017-11-21 09:22:31 UTC
Please attach an example document.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 James D Howard 2017-11-22 04:22:35 UTC
Created attachment 137908 [details]
Example reproducer (.tgz)

Attached file - Bugz-113962-Example.tgz - contains an .odg and 2 image files: one .jpg, another .gif

To reproduce:
1. make a new empty directory && cd there
2. extract: tar -xvf Bugz-113962-Example.tgz
3. open NetDiag.odg
4. Do [Insert]->[Image...] && select the file Fconnector-RG-6-ActuallyJPG.gif
5. Do [ Open ]

NOTE: The problem [Insert]->[Image...] occurs with the file
   Fconnector-RG-6-ActuallyJPG.gif
As the current file name implies the actual content of the file is in .JPG format, but the "name" of the file is using the .gif extention.  Don't know origin of that confusion; it was downloaded from a Google images search that way (then renamed as you see here, but keeping the .gif extension).

Result:
Image appearing on the drawing canvas is the already-present picture of a
D-Link desktop 8-port switch

Expected result:
1.) Image appearing on the drawing canvas is the image actually in the file -
   that of an RG-6 F-connector
-- or --
2.) An error message that the file actual content (.JPG) is not of the
   type implied by the file name suffix (.gif)

NOTE: Even though there is a disagreement between the file name suffix
(".gif") and the actual content type (".jpg", as shown with the "file"
shell command), other image viewers - including 'GIMP', the Midori, Opera, Firefox and Chrome browsers - pick up and render the file as per actual
content.

NOTE: I find that the 'Ristretto Image Viewer' does notice the
disparity and shows a blank image and a top banner error message.
Comment 3 Buovjaga 2017-11-22 14:54:26 UTC
Ah, very cool... this is a GTK3-only issue! VCL backends kde4 and gen work fine.

Other weirdness: with GTK2, it says "Image filter not found".

It is truly dependent on the wrong file extension. GTK3 works fine, if I rename the file to .jpg.

Arch Linux 64-bit
Version: 6.0.0.0.alpha1+
Build ID: 1d9eed341db208f11de6f020538dfdb74a5c48dd
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on November 22nd 2017
Comment 4 Caolán McNamara 2017-11-23 16:32:21 UTC
well, gtk2 also I Imagine as well as gtk3. Looks like the gif is detected as a jpg, that filter set on the dialog as the current filter as a place to stash the detection of the true type and the generic file dialog will return that, while the gtk file picker will refetch the type based on the filename.
Comment 5 Commit Notification 2017-11-23 20:28:48 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c9a3195068bf00e00290f363d5028e9986bbba6

Resolves: tdf#113962 save detected filter outside file dialog

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.