Bug 124411 - Impress: dragging image from file browser to slide replaces
Summary: Impress: dragging image from file browser to slide replaces
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.1.5.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.3.0 target:6.2.4
Keywords:
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2019-03-28 23:12 UTC by sam tygier
Modified: 2019-04-04 17:06 UTC (History)
3 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 sam tygier 2019-03-28 23:12:00 UTC
If I drag and drop an image from a file browser (caja) into a slide, it removes and replaces the main text area.

1) Create a new presentation.
2) Set slide layout to "Title slide" or "Tile, content"
3) add some text to the main text area
4) Drag an image file from a file browser into the slide

Expected behaviour

A new image object is created.

Actual behaviour

The main text is deleted and the area is fill with a stretched version of the image.

Happens in
Version: 6.1.5.2
Build ID: 6.1.5.2-2.fc29
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); Calc: group threaded
and
Version: 6.2.2.2
Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 1 V Stuart Foote 2019-03-29 19:29:28 UTC
Can not confirm on Windows builds.

Even with text box on slide canvas selected, a drag-n-drop of TIFF, PNG, JPEG image will not clobber the text or the Text Box object. And, only if the Text box has focus--and the cursor drop point *is inside* the Text Box object, will the image expand to fill the Text Box's frame--but that is immediately obvious and can be undone.

Otherwise the drag-n-drop functions as expected, drop onto the slide/drawing canvas and position & size as needed.

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 5cb2db6dd7d234a610a6501668a9901af8472b7f
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-26_23:06:31
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

Version: 6.2.1.0.0+ (x64)
Build ID: dfa1f1f872c418e89757a3985979b79e94c12fcc
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 2 sam tygier 2019-03-29 21:16:30 UTC
Thanks, seems the bug is only in GTK3.

If I force the GTK2 backend with:
SAL_USE_VCLPLUGIN=gtk /opt/libreoffice6.2/program/simpress

then I do not get the issue.
Comment 3 raal 2019-03-30 17:28:56 UTC
Confirm with Version: 6.3.0.0.alpha0+
Build ID: 82463bdde75447d45e0cd6ed9ab579e0e51ea912
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 

text box is deleted.
Comment 4 Caolán McNamara 2019-04-01 12:43:50 UTC
It seems that its defaulting to "move" rather than "copy", there's evidence in the macosx port that this situation arose there too and the default should depend on if the drag source is ourself or not
Comment 5 Commit Notification 2019-04-01 14:33:01 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/d9b746c6393a7c39591ad2334fd6313a988050e6%5E%21

Resolves: tdf#124411 default dnd to MOVE for internal and COPY for external

It will be available in 6.3.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 6 Caolán McNamara 2019-04-01 14:39:44 UTC
fixed in master, backports in gerrit
Comment 7 sam tygier 2019-04-02 17:16:54 UTC
 d9b746c6393a7c39591ad2334fd6313a988050e6 Fixes this for me. Can the patch be back-ported to the stable releases?

Also, I am a bit confused by the 'move' and 'copy' names. When dragging and dropping between 2 folders/disks in a file system 'move' means that the source gets deleted, which is not what you want when you drag an image into an LO document. 'Insert' and 'replace' would be clearer.
Comment 8 Xisco Faulí 2019-04-04 09:25:39 UTC
Verified in

Version: 6.3.0.0.alpha0+
Build ID: 93f1c3665fcdc31c36078f179ac37fd69d3ebb00
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

@Caolán, thanks for fixing this issue!!
Comment 9 Commit Notification 2019-04-04 09:28:28 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/eaaec2de4eef3fd283f387d2d5888a6d4f46c25b%5E%21

Resolves: tdf#124411 default dnd to MOVE for internal and COPY for external

It will be available in 6.2.4.

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

Affected users are encouraged to test the fix and report feedback.
Comment 10 sam tygier 2019-04-04 17:06:20 UTC
Thanks. Fixed for me in:

Version: 6.2.4.0.0+
Build ID: eaaec2de4eef3fd283f387d2d5888a6d4f46c25b
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded