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
Please attach an example document. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document.
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.
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
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.
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.