Should chat input box block typing when sending?

So currently chat input box uses same post status form which blocks all interaction while it's sending, it makes sense for statuses. When chatting you often want to start typing the next message immediately after hitting enter, but this mechanism blocks it, it becomes very clunky.

The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.

The challenge is handling posts that fail to send if we unlock the form immediately. they'd have to retry sending a few times and somehow indicate that they haven't been sent.

This can probably be done by introducing optimistic posting (with the help of the idempotency key) and keeping track of each message (e.g., (sending | delivered | error)) and styling them accordingly, I think. But BE would need to broadcast the idempodency key via WS too since sometimes the WS event can arrive earlier than the HTTP response and such event would be taken as a different message.

We could maybe do it simpler without needing extra support, we don't block the entire form but just block send, so that user can start typing the new message before the previous one has sent but just can't post it, I think it would totally eliminate the biggest issue we have with it currently.

this feels like a crutch. Sure we can block send, but what if message errors out, what do we do? Erase new draft and put old one instead? Let errored message go into void? Show error "your message: $MESSAGE was not sent" so that user can copy it?

IMO having chat bubble with "not sent, click to retry", while being an awful situation is still best UX out all known solutions.

retry the message until it sends is my first solution, if the connection is borked you're not gonna send anything more anyway

you still want to type a draft because connection can come back soon.

yeah you can type the draft for the next post, just not send it

Blocking text input while sending is a terrible, terrible UX. People often type message, hit ENTER (or SEND/send shortcut i.e. ctrl-enter) and keep on typing next message. Disabling text field would make it lose focus, which will cost user some keystrokes going into the void (and pray mercy they aren't using VimFX/SakaKey/Vimperator or similar addons), not to mention we will probably need to re-focus it after it becomes enabled which could be pain.

yes it's bad, that's what we're doing right now, changing it has it's own drawback why the issue

I think Riot did something like that and it was horrible.

In Soapbox FE we push a fake message into the chat as soon as the user sends, and then it gets overridden with the real message on response. It gives a UUID to this fake message so it can keep track. It feels fast.

Screen_record_from_2020-09-03_10.52.45

yeah that's really nice, I'd like to have something similar

what does it do when it fails to send?

It stays semi-transparent. It should probably turn red and maybe have a "Try resend?" button.

This really seems like a good solution, we should probably just do the same.

automatic retry is what I'd try first when it fails to send

automatic retry really should be enough, if it fails just let it fail and mark as red or something, the user can send new message.

Looks nice.

A small note. It seems that right now SoapboxFE doesn't sync your own messages when the same chat is opened in different tabs. Since PleromaFE does the sync, the same approach makes duplicate messages being added due to not being able to associate the fake message with the one coming from the WS streaming if it arrives earlier than the HTTP response.

More specifically:

When the user sends a new message,

1. The fake message is added to the list.
2. The WS streaming pleroma:chat_update event for that message arrives earlier than the HTTP response. Since it doesn't contain the fake id and can't be associated with the request/response cycle, it can't replace the fake message and so the duplicate message is created.

I think we would need to broadcast something like the idempotency key via the pleroma:chat_update streaming event so that we could associate the fake message with the one coming from the WS streaming event and avoid the duplicates. This way clients can do both the sync and the optimistic posting.

mentioned in merge request !1228 (merged)

mentioned in issue pleroma#2126 (closed)

added Better behavior Discussion labels