Await send request; handle failure

[gnprice]

If you're using the app, then step into an elevator (or otherwise lose your network connection), and hit send on a message, the current experience is pretty bad: the message just vanishes, there's no error message, and you don't even get back the text you wrote so you can try again.

The UX we'd ultimately like to have here is local echo, with an "outbox" system that can retry the send when you're back on the network:

• #576
• #133

But those are complex to get right, and I think we won't get to them in the next few months. There's a much simpler thing we can do that would greatly mitigate this, so we should do the simpler thing first.

Specifically, when you hit the send button:

• We'll put the compose box and send button into a disabled, "working on it" state — for example the text inputs might be grayed out, and the send button showing a spinner instead of the "send" icon.
• In that state, we'll let you select the text from the input box in order to copy it, in case you decide it's taking too long and want to give up.
• We'll await the result of the send request. If it succeeds, the send is done and we can proceed just like the send button does now: clear the input and take it back to a ready state. If it fails, we'll show an error message and make the input ready again, but still holding the text the user entered.

(To keep this simple to implement, we'll only be waiting for the send request to complete — not for the message event, which is what causes the message to appear full-fledged in the message list. This means that the message might appear in the list before or after the compose area goes back to ready. I'm hopeful that in practice this won't often be bothersome, and will be better than the status quo. If we find we need to wait for the message event in order for the interaction to feel right, then that gets a lot closer to a full version of #133, and we'll re-evaluate whether there's still a simple version that makes sense.)

@terpimost will be preparing a more concrete design. Until that's ready, this issue isn't ready for implementation.

Thanks also to @terpimost for the feedback pointing out the need for this, in particular the elevator story :-)

[gnprice]

I've filed the first steps of this feature, which will already be useful in themselves, as a separate issue:

• #815

[terpimost]

Does this reflect the logic? https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=4031-13405&t=hE9wEtLE59jG5rUn-1

[gnprice]

That looks good, thanks!

I think we'll need to allow a much longer timeout than 5 seconds — sometimes people are on slow network connections (or flaky ones such that the network needs to retry the packets), and sometimes their server is slow. Something like 30 seconds is probably long enough.

Because that'll be a while and the user may want to give up and move on sooner, there's this item we had above:

In that state, we'll let you select the text from the input box in order to copy it, in case you decide it's taking too long and want to give up.

[PIG208]

The new design part of this is probably blocked by #915. I think we should move this to the "Launch" milestone as well.

[PIG208]

Following up here on a recent discovery while working on this.

It might be that this means that this strategy — the strategy described in https://github.com/zulip/zulip-flutter/issues/720 — just isn't going to work. On the one hand what the strategy calls for is to have a text field that (a) looks disabled and (b) really is disabled, not accepting input… but on the other hand, trying this UX out, I think we need (c) the keyboard to remain in place, just like it would if the text field still were accepting input. That's unavoidably going to be somewhat hacky — it's a keyboard that won't do anything, which risks a confusing UX — and it may be tricky to get TextField and friends to arrange such a thing for us.

I think the next step will be at least pushing this to the next milestone, or figuring out a replacement design, unless we decide to go straight to the "outbox+local echo" solution.

[gnprice]

I think the next thing we'll do here is probably to attempt a version of local echo (#576).

That means we'd bypass the specific design described above, for the reasons in the previous comment (and the discussion linked there). Leaving this issue thread open for now, though, as a way of tracking the user-facing need.

[gnprice]

We heard another report today of the unpleasant consequences of not yet having this:

Wrote four long messages and sent them. First one sent. Next three appeared to send, then after a long delay, got the error "Message not sent", "Software caused connection abort", and the messages are gone.

[gnprice]

Started a chat thread just now on how best to handle this situation: #mobile > handle failed send @ 💬

[gnprice]

I've filed #1441 to describe the new plan for handling this need. We'll track further work there.