sending a message is often delayed, sometimes buggy

[hpk42]

am using a recent master of core and desktop.

when i hit "ctrl-enter" for sending -- half the time it delays for 2+ seconds and sometimes the draft-text does not go away even after the message is posted (see screenshot). It feels like something is blocking. Currently, i can't offer much help in debugging but at least wanted to raise it, anyway.

[Simon-Laux]

maybe send me the log after it happened, maybe there is some error somewhere?

[WofWca]

This code is responsible for message sending and draft removal:

deltachat-desktop/packages/frontend/src/components/composer/Composer.tsx

Lines 140 to 153 in a5c0243

	const sendMessagePromise = sendMessage(accountId, chatId, {
	text: replaceColonsSafe(message),
	file: draftState.file || undefined,
	quotedMessageId:
	draftState.quote?.kind === 'WithMessage'
	? draftState.quote.messageId
	: null,
	viewtype: draftState.viewType,
	})
	/* clear it here to make sure the draft is cleared */
	await BackendRemote.rpc.removeDraft(selectedAccountId(), chatId)
	// /* update the state to reflect the removed draft */
	window.__reloadDraft && window.__reloadDraft()

It calls __reloadDraft, which is where the input text is reset, I believe:

deltachat-desktop/packages/frontend/src/components/composer/Composer.tsx

Line 448 in a5c0243

inputRef.current?.setText('')

This also might have to do with other code, e.g. message list re-rendering and re-fetching being too slow.

[hpk42]

Can't comment on the code but the issues still appears often for me -- on desktop i now take care especially in group chats, to very carefully check if the message went out, even if the input field continues to have the full draft message. I then need to remove it manually.

[WofWca]

Is it bad on all your Delta Chat accounts?

[hpk42]

On Thu, Sep 19, 2024 at 23:59 -0700, WofWca wrote: Is it bad on all your Delta Chat accounts?

Only my (big) main accounts exposes the problem, and only in bigger group chats. In other accounts i am not really part of larger chats. Superficially, this points to some event-bubbling/timing problem? I also never had this problem on Android.

[WofWca]

@Simon-Laux could you explain what's the point of __reloadDraft() instead of clearDraft() #2529 ?

[Simon-Laux]

@Simon-Laux could you explain what's the point of __reloadDraft() instead of clearDraft() #2529 ?

to show the actual state of the draft in core. maybe could make sense to pass a chatId as argument there to make sure it is never called incorrectly while switching chats?

[WofWca]

But I mean, can it so happen that there is gonna be a draft after sending a message? Why make an async call. Would clearDraft() + __reloadDraft() make sense at least?

[WofWca]

@hpk42 A fix for a related issue (deltachat/deltachat-core-rust#6036) has been released with Delta Chat Dekstop 1.47.1. Please report whether things improved.

[hpk42]

K, i'll close and will re-open or open a new issue if it re-appears.
thanks!

[WofWca]

Hmmm I think I just encountered this issue (draft not getting removed) myself, on 1.49.0 (git: v1.33.0-1229-gc574dd42)

Could have to do with #4144 where we switched to throttle to save draft.

I suspect this mostly happens on heavier accounts.

[hpk42]

yesterday, on desktop-main the draft did not disappear often, while the message was sent out. The draft was never cleared. This happened around 5 out of 6 times when i sent a message. Today it doesn't happen so much -- but maybe today is also less chat activity on my account, not sure. Also regarding other problems with message sending (eg on android deltachat/deltachat-android#3489 ) i am wondering if there should be a more direct "send draft message" API so that the UI executes an atomic action on core, that adds/sends the message and clears the draft in one go.

…

On Sat, Dec 14, 2024 at 02:34 -0800, WofWca wrote: Hmmm I think I just encountered this issue (draft not getting removed) myself, on 1.49.0 (git: v1.33.0-1229-gc574dd42) Could have to do with #4144 where we switched to `throttle` to save draft. I suspect this mostly happens on heavier accounts. -- Reply to this email directly or view it on GitHub: #3586 (comment) You are receiving this because you modified the open/close state. Message ID: ***@***.***>

[Simon-Laux]

i am wondering if there should be a more direct "send draft message" API

yes, that is actually the main idea of the composer rewrite. keep more of the state in core and don't recreate the draft every time it is changed.

[r10s]

i am wondering if there should be a more direct "send draft message" API
so that the UI executes an atomic action on core, that adds/sends the message
and clears the draft in one go.

this is already in place since since deltachat/deltachat-core-rust#2887: you can send_msg(draft_id) that sends the message out and clears the draft in one go (send_msg still takes a message object in that case, changing that to take a msg_id may make sense, but that is more cosmectic and not really the issue)

there was also deltachat/deltachat-core-rust#4839 added a long time ago, to make webxdc-staging work. but not totally sure, what is missing there, the corresponding issue to "to send webxdc app staged in draft with JSON-RPC" (#4643) was reopend a year ago.

so, from view of core/cffi and maybe even jsonrpc, "sending and clearing draft" is mostly fine - it is just that things are not (always) used that way (also not on android outside webxdc-drafts iirc)