Works for me with a JPEG file in a Writer document :

LibreOffice 3.5.0rc1 
Version ID : b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87

Mac OSX 10.6.8


Alex

But with Mac OS X 10.7, it doesn't work, same behavior, i can't drag and drop an image.jpg from desktop to Writer. It has been tested with the stable 3.5 release.

Bug still present in release 3.5.1 with Mac OS X 10.7.3

Bug still present in release 3.5.2 with Mac OS X 10.7.3

Same behaviour for me, REPRODUCIBLE with 3.5.2 on 10.7.3

Problem still here: LO 3.5.5 with OS X 10.7.4.

I can't confirm this issue myself (I have to stay with MacOS X 10.6.8 for technical reasons), but I think we can set the status to NEW because of the independend reports (three users) -- something must be really wrong here.

@ Thorsten Behrens:
I CC you about this issue because you are our MacOS expert. Please take a look at it; the issue is limited to MacOS 10.7, but is nevertheless quite annoying especially for Mac users which are quite accustomed to drag-and-drop editing. Thank you very much in advance!

WFM on Mountain Lion 10.8.1 with
Version 3.7.0.0.alpha0+ (Build ID: 4deb9d4)


1) Select an image in my Downloads folder from the Dock
2) Drag n drop that image onto an empty Writer document.
3) Image is inserted into Writer document.


Alex

Correction :

I can reproduce the behaviour, but only when the image is on the Desktop. In that particular case, the image gets opened in Draw.

Confirming.


Alex

I suspect that this bug and bug 54432 are one and the same : LO on Mac OSX > 7 does not support DnD of images from other applications.

Alex

@Thorsten : your call ?

I made some more tests on macOSX 10.8.2 with LO 3.6.2.2

Drag a image png or jpg from desktop or even from a folder to write page : in both cases, the image is opened in Draw.

With an other application, NeoOffice, both images can be DnD to writer page.

The problem has be announced in january 2012 and it is still there...

May we hope a fix soon ?

PS Juste tested with Version 4.0.0.0.alpha0+ (Build ID: e05988), same problem, impossible to DnD an .jpg or .png file from the desktop or a folder to a wrtiter page

Confirmed on OS X 10.7.5.

Mac OS 10.7.5. / LibreOffice 3.5.7.2
With the release of LibreOffice 3.5.7.2, it is impossible to insert an image into a document writer by sliding from the desktop. The picture does not fit in the text. This image is opened directly and automatically in Draw.
And this problem did not occur with earlier versions.

Here some tests:

MacOS 10.6.8 with LO 3.5.4.2 : Dnd (from the desktop or elsewhere) -> Images are integrated in Writer = OK

MacOS 10.7.5 with LO 3.6.4.3 : Dnd (from the desktop or elsewhere) -> Images open Draw 

MacOS 10.7.5 with OO 3.6.4.3 : Dnd (from the desktop or elsewhere) -> Images open Draw

MacOS 10.8.2 with LO 3.6.4.3 : Dnd (from the desktop or elsewhere) -> Images open Draw

Tested on MacbookPro, iMac and MacPro.

I confirm the problem.
In an environment where the drag and drop is a common use for all media (not just pictures), it is surprising that this bug is still not fixed.
Please fix it quickly !

*** Bug 59132 has been marked as a duplicate of this bug. ***

It's been a year now!

This is a bug so prominent that probably every single LO on Mac OS >= 10.7 user has come across and been annoyed by it. And remember that Mac folks tend to be less technical, so the fraction of Mac users creating a bugzilla account when bothered by a bug is going to be smaller than the corresponding fraction of Windows and Linux users.

I don't really understand...

I have just tested the fresh new LO 4.0 on MacOSX, hoping that the bug has disappear. So i drag a picture from my desktop to Writer and... Draw opens. 

So the bug is still present in version 4.0 and i send an issue about it in january 2012.

An i repeat, the bug isn't present in NeoOffice...

So please, can you correct the bug ?

Thanks

Christian

can't commit time to this currently - but if someone is interested in fixing this, can gladly lend a helping hand. FWIW, drag and drop code to start unwinding this is vcl/aqua/source/dtrans/DropTarget.cxx.

2 months later the last comment, and no correction yet !!!

This bug is really annoying for Mac Users in 10.7 and 10.8. In school labs, when we want to convince users to migrate from Office to LibreOffice, and they see that LO can't accept drag and drop, that's not good.

Just tested now with the new LO 4.0.3.1 with 10.8, bug still present and even worst.

- Drag picture (.jpg) from a folder to a document writer --> it opens a drawing page and paste the picture.

- Drag picture (.jpg) from the desktop to a document writer --> nothing happens.

In LO 3.6.5, dragging a picture from desktop or a folder to Writer always open a drawing page. Here, with LO 4, it's different.

In both cases, dragging a picture to writer must paste the picture on the writer page.

Please, can you fix this bug 

Thanks

Christian

I'm starting to work on this, I've posted a mail in developer's list and I'll also post it here:

The image when dropped into the Libre Office application opens Draw no matter what the source (desktop or any other app) is what the target (writer,impress etc.) is.
I'm not really sure which module is taking care of this, I found these two files:
http://opengrok.libreoffice.org/xref/core/vcl/aqua/source/dtrans/DropTarget.cxx
http://opengrok.libreoffice.org/xref/core/vcl/aqua/source/dtrans/DragSource.cxx
But I'm not sure if they actually do anything. Any head start will be highly appreciated!

Hi,

In 4.0.3.3, bug still present with Mac OS X 10.7 and 10.8, but as dragging a jpg file to writer from a folder opens every time draw, dragging a jpg file to writer from desktop makes nothing, it isn't allowed.

Bug isn't present on NeoOffice

Hi,


In 4.0.4, bug still present with Mac OS X 10.7 and 10.8.

So, it seems that nobody can (or want to) correct this bug. This bug has now more than 18 months 

Bug isn't present on NeoOffice so it could be possible to correct it, no ?


:-((  Christian

@Tor, Khaled,

I'm adding you to CC, thanks to you LO Mac version quality has increased significantly in the past months, so if possible could you take a look at this *very annoying* UX bug when you have time?

Any help would be appreciated, thanks in advance. 

Best regards.
Emir

can any Mac user test 4.1.0 release and tell us if the bug is still present, fixed or different?

I tested on master and it is still there.

I spent a day trying to fix this, no cigar. The code in vcl/aqua/source/dtrans is weird, that's for sure. (Just look at how it treats pasteboard data of type TIFF as it was PNG, huh?)

If it is any consolation, AOO has this same bug...

Gawd I hate this shitty code.

And this is supposed to be an Easy Hack? LOL.

moving frm the mab3.6 page to the mab4.0 page.

according to Tor's comments this is annoying either for users and developers. :-)

(In reply to comment #28)
> I spent a day trying to fix this, no cigar. The code in
> vcl/aqua/source/dtrans is weird, that's for sure. (Just look at how it
> treats pasteboard data of type TIFF as it was PNG, huh?)
> 
> If it is any consolation, AOO has this same bug...

I also spent some time on it but hardly understood the root of the problem. Apple had changed the protocol for DND in 10.7 but the one used in dtrans still works.

Fresh try today, tried two different approaches to understand what is going on and what needs to be changed/fixed. No success.

Removing EasyHack as per Comment 30.

This WORKSFORME totally fine with OS X 10.8.4 and LO 4.1.0.4.

Can anybody of the 13 CCs confirm this is still happening with the latest LO release and current OS X?

I cannot reproduce this problem.

James: it definitely does not work for me on OS X 10.8.4 and LibreOffice 4.1.0.4... (or LibreOffice master).

Are you sure you are looking for the right thing:

If you drag an image file (for instance a .jpg or .png) from the desktop on top of a Writer document window, does the image become inserted into the Writer document, as if you had done Insert>Picture>From File...? That is what *should* happen. For me it does not; instead a new LibreOffice Draw document window opens, editing the image file. That is the bug.

Just tested with LO 4.1.1 and MacOSX 10.8.4 and same as i explained the 2013-05-15 :

Bug still present with Mac OS X 10.7 and 10.8, but as dragging a jpg file to writer from a folder opens every time draw, dragging a jpg file to writer from desktop makes nothing, it isn't allowed.

I repeat that NeoOffice hasn't this bug, so it should be possible to fix it, no ?

:-))  Christian

Bug seldom go away by themselves so no need to repeat yourself.

I confirm it with LO4.1.1.2 and OSX 10.7.5

edited summary notes to match desctiption with similar bugs about drag & drop (Bug 50091 and Bug 61233)

Bug still present with LibreOffice 4.1.2 and Mac OSX Mavericks.

It will soon be two years since I opened this bug ...

Confirmed:4.2.0.3:OSX

Adding 4.2 MAB.

MAB 4.1 is corret, because this bug persists there and 4.1 is still older than 4.2, and yet under development.

/me closes his book of LO policies :)

Confirmed with LO 4.2.3 in MacOSX : dragging a jpg from the desktop to writer makes nothing and dragging a jpg from a folder to writer opens a draw document

This is still the same for Impress in 4.2.3.3 and INCREDIBLY ANNOYING. 5-10 extra clicks for every single image. How is this bug still not fixed after 2 years.

4.1.x reached end of life.
moving this still reproducible bug to mab4.2 list.

*** Bug 79849 has been marked as a duplicate of this bug. ***

Bug Confirmed with prerelease LO 4.3.0.2 in MacOSX 10.9 : dragging a jpg from the desktop to writer makes nothing and dragging a jpg from a folder to writer opens a draw document. Same with png.

So the bug is now 2,5 years old, happy birthday :-((

Sorry for this humor, but we are managing macs in classes, trying to convince teachers and students to use LO and this bug is very annoying.

Christian :-))

confirmed 4.3 final release OS X 10.9.4.

Wow, this is sad. Imo, drag and drop is the most used and most intuitive way to get an image into any application.

If this is broken in LO writer on OS X, this is a major usability problem. Non tech savvy users will drag and drop and leave LO frustrated (with good cause in this case).

Since Tor was unable to fix this, sounds like a rewrite of this code has to happen.

Adding 4.3 MAB, removing 4.2 MAB.

(In reply to comment #50)
>, sounds like a rewrite of this code has to
> happen.

IMHO a total rewrite of Mac code has to happen. LibreOffice offers absolutely no UX on OS X platform, it just offers technical word processing/spreadsheet/presentation functions.  

I would love to see LibreOffice on Mac as a totally separate application with no shared code/ifdef/whatsoever.

(In reply to comment #50)
> ....
> 
> Adding 4.3 MAB, removing 4.2 MAB.

hi Foss,
this is not the correct procedure.
you cannot move a 4.2 MAB to 4.3 MAB list until 4.2.x reaches the EOL.

I thought the latest? Ok it's the oldest. Sorry, then reverting or keep both? Tommy27 if you know what's standard policy, could you take the according action?

reverting to MAB4.2
if bug will be still present after 4.2.x end-of-life (i.e. 4.2.7 release) it will be moved to MAB4.3

Bug still present in last version of LO 4.3.1.2

(In reply to ramuntcho from comment #55)
> Bug still present in last version of LO 4.3.1.2

Yes, and also in 4322, but no surprises there.


@ramuntcho : the bug is unlikely to go away by itself. Just understanding how the code is supposed to work has represented a serious challenge for at least two developers. This is not an easy bug to fix. The code from NeoOffice can't simply be taken and plugged into LibreOffice because of the different licences that the two projects have.

Neo - GPL
LO - LGPL3/MPL

the licence systems are incompatible.

So, the code has to be developed independently by someone willing and able to contribute it to the LO codebase. Until that happens, this bug will not get fixed, even if that means that "loads" of Mac users will try and then bin LO as a result.

Problem persists in 4.3.1.1 release, using Mac OS 10.9.

Considering that this bug is only active is OS > 10.7, and 4.4 is not supported below 10.7, this could be the end of the line for some LO users unless the bug is fixed.

LibO 4.2.x reached end of life.
this is still present in 4.3.x so I'm moving it to mab4.3 list.

Adding references to AOO's bug tracker and also the bibisect done by Matthew in bug 61233 comment 9, though i doubt it maybe that as i dont think Kohei's code would have landed in AOO.

*** Bug 61233 has been marked as a duplicate of this bug. ***

And this bug is present also in the new LO 4.4.1.2 :-((

Is anybody else working on this?

I've submitted a patch for review 
https://gerrit.libreoffice.org/#/c/15683/

mmeof2 committed a patch related to this issue.
It has been pushed to "master":

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

tdf#44621: Fixed drag and drop in OSX 10.7+

It will be available in 5.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.

Thanks Manik for the patch and hope we can backport this to 4.4 as well.

@Alex, foss: Can you guys verify that this is fixed.

Verified. Manik, I can't thank you enough. This has been a major annoyance on OSX and it's great to announce your fix is working.

(In reply to Yousuf (Jay) Philips from comment #66)
> Thanks Manik for the patch and hope we can backport this to 4.4 as well.

This should be backport(-able) as both the functions I used are are present in OSX 10.0+



@steve happy to hear that, this bug was probably causing LO to lose some share (among osx users) .

(In reply to Manik Malhotra from comment #68)


> 
> @steve happy to hear that, this bug was probably causing LO to lose some
> share (among osx users) .

Superb contribution for those of us felt left out in the cold :-)
You've also managed to kill off two other bugs with the same commit, heartfelt thanks !

*** Bug 50091 has been marked as a duplicate of this bug. ***

*** Bug 54432 has been marked as a duplicate of this bug. ***

(In reply to Manik Malhotra from comment #68)
> This should be backport(-able) as both the functions I used are are present
> in OSX 10.0+

As it has been confirmed to work, please do backport it to 4.4. I tried cherry-picking it from gerrit, but it wouldnt go through.

(In reply to Yousuf (Jay) Philips from comment #72)
> (In reply to Manik Malhotra from comment #68)
> > This should be backport(-able) as both the functions I used are are present
> > in OSX 10.0+
> 
> As it has been confirmed to work, please do backport it to 4.4. I tried
> cherry-picking it from gerrit, but it wouldnt go through.

I don't know how to do that. Do I need to check out specifically 4.4 code base?
Can you guide me?

(In reply to Manik Malhotra from comment #73)
> I don't know how to do that. Do I need to check out specifically 4.4 code
> base?
> Can you guide me?

You would need to follow the 4.4 branch on git

   git checkout --track remotes/origin/libreoffice-4-4

Then make the changes as you would normally and then send it to gerrit

   git push origin branch_name:refs/for/libreoffice-4-4

Where branch_name is the name of the branch with the patch. Hope this helps.

Created attachment 117178 [details]
4.4 diff

I have attached the diff for 4.4 branch please check and apply.

*** Bug 92748 has been marked as a duplicate of this bug. ***

Comment on attachment 117178 [details]
4.4 diff

The diff contains unrelated changes (the binary blobs, why are there ar all?).

Any reason you didn’t submit this through Gerrit? That is the point of having a Gerrit instance, not having diffs floating around and getting lost.

Ignore the binary diffs, just look at the DropTarget.cxx and DropTarget.hxx diffs

I'm not able to build 4.4 as I'm missing something from automake. I had a hard time getting the 4.4 code itself. Since Yousuf couldn't merge the original diffs I provided diffs specifically for 4.4

Many thanks for this job, it's working very well in LO 5.0 :-))

I've added Manik's changed into 4.4 : https://gerrit.libreoffice.org/#/c/17461/

mmeof2 committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b3364c13ced09d903d7390febb36f35faf3baa86&h=libreoffice-4-4

tdf#44621: Fixed drag and drop in OSX 10.7+

It will be available in 4.4.6.

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.