ui: preserve input text until message send succeeds - #562
Conversation
Prevents input buffer from clearing immediately upon hitting enter, avoiding message loss during silent network drops. The entry field is now cleared only when SendMessageNotify confirms a successful transmission.
|
Is there any mechanism preventing the user from sending the same message twice? |
|
I think that's a valid point. I will see if I find a way to avoid sending the same message twice and I will update asap. |
|
I think a good approach would be to check if the user is trying to send the exact same message in less than a few seconds and in that case skip it. What do you think? |
…ce after changing nchat behavior to keep the input text until message send succeeds
|
I added a 5 seconds "cooldown" for messages that are exact the same. |
|
Another possible solution would be to show the sent message on history and mark with a signal showing it failed to deliver. That is what web.whatsapp.com does. |
|
I just noticed that Telegram doesn't seem to discard the message we send offline, it resumes and send the message when the connection is restored. But WhatsApp discards the message after a few seconds (30-60 seconds) and we end up: 1. not knowing the message was lost, and 2. loosing what we have wrote. |
…xt (avoiding clearing the input field if it is a file transfer
Prevents input buffer from clearing immediately upon hitting send shortcut, avoiding message loss during silent network drops. The entry field is now cleared only when SendMessageNotify confirms a successful transmission.
Problem
Currently, when a user sends a message, UiModel::Impl::SendMessage() immediately clears the input field buffer (entryStr) before the background network thread ever transmits the payload or receives a confirmation from the backend protocol.
If the user suffers a temporary or silent network disconnection, the message is dropped entirely by the backend, but the text has already vanished from the interface. The user has no way of knowing the message failed to send unless they monitor log traces, and their typed text is permanently lost.
Proposed Solution
This PR shifts the responsibility of clearing the input entry state from the optimistic SendMessage() invocation to the asynchronous protocol response handler.
src/uimodel.cpp (SendMessage): Removed the immediate execution of entryStr.clear(), entryPos = 0, and UpdateEntry().
src/uimodel.cpp (MessageHandler): Inside the SendMessageNotifyType switch case, we now explicitly check the sendMessageNotify->success state.
On Success: The message buffer and cursor position for that specific profileId and chatId are cleared and the UI is updated.
On Failure: The state is left intact. The text remains visible in the input field, allowing the user to easily attempt a re-send once their network stability returns.