Opened 3 years ago

Closed 2 years ago

#18232 closed defect (fixed)

macOS Mojave: Starting drag with 2+ files in wxFileDataObject crashes

Reported by: botg Owned by: csomor
Priority: high Milestone:
Component: wxOSX Version: dev-latest
Keywords: Cc: oneeyeman@…
Blocked By: Blocking:
Patch: no

Description

Starting a drag with a wxFileDataObject containing more than one item crashes the program on Mojave, happens both on master as well as on the WX_3_0_BRANCH.

It can reproduced in the dnd sample if modified using the attached patch, then dragging a file closes the program.

On master running it in lldb doesn't print anything (separate bug?). Interestingly enough the return code is 0, not even indicating that something is wrong.

On WX_3_0_BRANCH however running it in lldb prints the following:

2018-09-27 10:59:59.907586+0200 dnd[40870:510928] [General] There are 2 items on the pasteboard, but 1 drag images. There must be 1 draggingItem per pasteboardItem.

See attached lldb.log for details

Attachments (2)

lldb.log download (6.3 KB) - added by botg 3 years ago.
reproducer.diff download (404 bytes) - added by botg 3 years ago.

Download all attachments as: .zip

Change History (16)

Changed 3 years ago by botg

Changed 3 years ago by botg

comment:1 Changed 3 years ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

comment:2 Changed 3 years ago by csomor

are you on the dev releases ? does the same happen on 10.14.1 b1 ? I don't have 10.14.0 anymore ...

comment:3 Changed 3 years ago by botg

Yes, problem persists in 10.14.1 Beta (18B45d).

comment:4 Changed 3 years ago by csomor

at least we're not the only ones ...

https://openradar.appspot.com/44135683
https://forums.developer.apple.com/thread/107824

being able to have more items really makes sense ... I'll look at what happens on the pasteboard if I start from finder ...

comment:5 Changed 3 years ago by csomor

  • Priority changed from normal to high

comment:6 Changed 3 years ago by csomor

OK, the only way to avoid the crashes was to rewrite dnd support using NSPasteboard instead of the PasteboardRef from Application Services, I'll clean up so that I can support clipboard and dnd on iOS with the same API and commit, I won't be able to put this into 3.0 however.

Last edited 3 years ago by csomor (previous) (diff)

comment:7 Changed 3 years ago by oneeyeman

  • Cc oneeyeman@… added

Stefan,
Did this ever find its way into the code?

Thank you.

comment:8 Changed 3 years ago by bmiller

  • Cc bmiller@… added

I just ran into this one myself -- two items in a wxFileDataObject under Mojave.

Looking at the code I thought it was because dragImage was deprecated.

Apple says to use; beginDraggingSessionWithItems:event:source: now.
[​https://developer.apple.com/documentation/appkit/nsview/1483791-begindraggingsessionwithitems?language=objc]

Is there a patch hanging around that uses NSPasteboard mentioned by Stefan?

comment:9 Changed 3 years ago by csomor

I still have it in my sandbox. It was not possible to replace things partially, so I've been reluctant. I'll recheck things and make a PR.

comment:10 Changed 3 years ago by csomor

ok, I'll prepare a PR, but while testing former and new implementation I found out that under 10.14.4 beta 5 the bug in macOS has been fixed. Could those with access to the betas verify, whether the bug is indeed corrected ?

Thanks

comment:11 Changed 3 years ago by csomor

and no - deprecation does not mean error, so a crash will not be caused by a deprecated API.

comment:12 Changed 3 years ago by bmiller

  • Cc bmiller@… removed

Hi Stefan, I just installed the 10.14.4 beta and can confirm that Apple has fixed the multi-file drag issue!!!

Again, thanks for all your work over the years - it's extremely appreciated.

comment:13 Changed 3 years ago by csomor

Hi Bill, thanks for testing, and you are very welcome :-)

perfect, I'll clean up the PR and post once it's ready for testing, but I'm glad if we don't have to hurry, and can test things thoroughly

comment:14 Changed 2 years ago by vadz

  • Resolution set to fixed
  • Status changed from accepted to closed

IIUC this was supposed to be fixed by f83577df451e492a419246a6f67ed26eefae1e5b and I can't reproduce it with 10.14.4 using the attached patch.

Note: See TracTickets for help on using tickets.