drag'n'drop unreliable sometimes

[r10s]

sometimes, drag'n'drop is unreliable and is just not working, took me quite some time to make this reproducible.

but here is an approach on macos13.6 with deltachat1.42.0:

1. have a fresh PDF-scan in the "Notes" app
2. drag'n'drop from the "Notes" app to "Delta Chat" -> this does not work
3. in the "Notes" app, right click the PDF and select "Save as"
4. drag'n'drop from the "Notes" app to "Delta Chat" -> now same drag'n'drop works

testing with other apps (as "Apple Mail" or "Find") drag'n'drop works already at step 2. - and doing that once, this also enables things to work with "Delta Chat". "Thunderbird" has the same bug, btw

maybe the format drag'n'drop offers changes once the file is exported or otherwise used - and that "Delta Chat" only supports one format.

video showing steps 1. to 4.:

Screen.Recording.2023-12-19.at.14.52.25.mov

[Simon-Laux]

works for me in macOS 14, though I can not exactly reproduce the scanning part, maybe it is a special state?

BTW while testing it I noticed that drag and drop of selected text does not work, while it works in vscode and even from notes to vscode, so it seems possible, but out of scope for us for now.

[r10s]

though I can not exactly reproduce the scanning part

long-tap the "Notes" App icon on the ios homescreen and hit "Scan Document" - if you're using the same apple account on macos and ios, you get the scan on macos.

however, this was just one example i figured out to make the issue reproducible. i have seen that randomly before as well and there may be also other cases where it happens.

[Simon-Laux]

Really seems to be sth when the file does not exist in apple's filesystem. not sure what the format then is, but I was not able to get the state yet, maybe I could get it when I connect the same Apple IDs on iPhone and macOS, but currently I don't want to do that.

[Simon-Laux]

please reopen if this is still an issue in new versions (macOS and deltachat desktop / electron).

[r10s]

i just retried on macos 14.5 with Delta Chat 1.46.1, it is still an issue and exactly reproducible in the same way as shown in the initial post.

maybe I could get it when I connect the same Apple IDs on iPhone and macOS, but currently I don't want to do that.

i think, this is needed for reproducing the way shown above.

there may be other ways for reproducing that do not require connection, but we do not know them (i expect the clipboard just to have some other format for a file that is not present in the filesystem yet)

however, if it is really only about the "Notes" app, it also seems fine to put that to resurrection and close it as "Not Fixed" - if we have a similar issue for other clipboard formats, we will remember

[Simon-Laux]

I bet this is an electron issue. I guess you could add a log statement in the drop handler and inspect the dev console if there is anything useful in it, if not then we can close it as won't fix.

to test add a log statement (console.info('dropped something', e)) to log the drop event e here:

deltachat-desktop/src/renderer/components/message/MessageListAndComposer.tsx

Lines 91 to 103 in 5679647

	const onDrop = (e: React.DragEvent<any>) => {
	if (chat === null) {
	log.warn('dropped something, but no chat is selected')
	return
	}
	e.preventDefault()
	e.stopPropagation()
	const sanitizedFileList: Pick<File, 'name' | 'path' | 'type'>[] = []
	{
	const fileList: FileList = (e.target as any).files || e.dataTransfer.files
	// TODO maybe add a clause here for windows because that uses backslash instead of slash

then look at the log to check if there is sth useful in e and post it in this thread.