ios: Share sheet partly hidden by keyboard, if keyboard was up when message was long-pressed

[chrisbobbe]

With #12, we'll have a way to share message content outside the Zulip app. 🎉

There's a glitch on iOS: if the topic or content input in the compose box was focused when you long-pressed a message, then this happens:

• The message action sheet opens in response to your long-press
• At the same time, the keyboard goes away
• When you tap "Share", the iOS share sheet appears
• At the same time, the keyboard reappears, blocking a large part of the share sheet

The keyboard should not reappear when you tap "Share". That seems to be caused by our Navigator.of(context).pop() call, which we do at the same time as we request the share sheet from iOS. Probably a fix will involve understanding why that .pop() call wants to make the keyboard reappear, and changing that behavior.

[gnprice]

Probably a fix will involve understanding why that .pop() call wants to make the keyboard reappear, and changing that behavior.

I imagine it's related to the keyboard having been open (because a text input was focused) on the previous route, i.e. the message list. The action sheet is a new, modal, route on the navigation stack; we pop that, so it's going back to the previous route; and then it restores the keyboard state, which seems like a helpful feature in general and is probably intentional.

There are probably ways to do this by fighting against the navigation system and that restore-previous-state behavior. Here's a way we can probably do it by cooperating with the navigation system: instead of popping the action-sheet route, we replace it with a new route that's the "share from Zulip" route. That route would do very little except (a) summon the system sharing modal, and (b) serve as a placeholder on the navigation stack, so that any state from the route before the action sheet doesn't try to restore itself until the sharing interaction is complete.

[Khader-1]

I also think it's related to a text input being focused, I imagine we can go with an alternative approach here.

The Problem

Share might take a long time (3 seconds with really slow connection) leaving the user wondering. check this out:

I am Not an expert in Ux but I imagine this behavior has room for improvements.

A Solution Proposal

We can show the user a loading indicator on the button it self and disable actions on the bottom sheet then we can show the share overlay without the need to Navigator pop until the share is handled we can pop once and for all. Please consider that this solution could be applied to all async actions in the bottom sheet not just Share

[chrisbobbe]

Thanks for your thoughts, @Khader-1, and for taking the time to make those screen recordings!

If I'm understanding correctly, your first screen recording (under "The Problem") doesn't actually show the bug this issue is about:

[…] the keyboard reappears, blocking a large part of the share sheet

In a quick test with the 0.0.12 beta just now, on my iPhone running iOS 17.3.1, the behavior closely resembles your screen recording. These steps match the bug report:

• The message action sheet opens in response to your long-press
• At the same time, the keyboard goes away

but then:

• When you tap "Share", the message action sheet closes and the keyboard briefly reappears
• Then the keyboard disappears and the share sheet appears

This is much better than a state where you can't use the share sheet because it's covered by the keyboard! 🙂 The brief reappearance and disappearance of the keyboard is unnecessary and would be good to fix, but at least it doesn't make the share sheet unusable.

Since the keyboard and the share sheet are both managed by iOS, probably there was an iOS update that fixed this conflict between them.

[chrisbobbe]

With this in mind, I'm going to close this issue, on the theory that it's possible to fix by upgrading to the latest iOS. If someone tries that and still sees behavior matching this issue's description, I'll reopen it.