You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(This is a milder version of #24, I think; the main symptom of #24 seems to have been fixed in an iOS update.)
If the topic or content input in the compose box was focused when you long-pressed a message, then this sequence is reproducible:
The message action sheet opens in response to your long-press
At the same time, the keyboard goes away
You tap "Share", and the message action sheet closes
The keyboard briefly reappears and disappears
The share sheet appears
It would be good to eliminate step 4.
The keyboard's entrance and exit are unnecessary and unexpected changes of context, so I'm labeling this as an accessibility issue (a-a11y). (The cognitive burden is particularly relevant for our users who are easily distracted, for example. It's also possible that some annoyance or confusion is created for screen-reader users; I haven't tested so I'm not sure.)
Here is a recording of the behavior, helpfully provided by @Khader-1 on issue #24:
The text was updated successfully, but these errors were encountered:
The keyboard's entrance happens because the message action sheet route is popped. The message-list route under it becomes the active route. That route has a focused text input (in the compose box), which makes the keyboard open.
Keep the message action sheet open until the share-sheet action completes successfully.
That might be the cleanest thing to do, actually. But we do have a comment in the current code, which I wrote, in the place where we dismiss the message action sheet before opening the share sheet:
// Close the message action sheet; we're about to show the share// sheet. (We could do this after the sharing Future settles// with [ShareResultStatus.success], but on iOS I get impatient with// how slowly our action sheet dismisses in that case.)
The words "how slowly our action sheet dismisses" refer to the exit animation of the message action sheet, which would start after the share-sheet action succeeded. I wouldn't put too much weight on my report of "impatience" there; I didn't spend much time in manual testing, and I'm open to changing my mind about how important it is to be quick there. 🙂
There's an alternative we could try, though, described by Greg at #24 (comment) :
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.
If that route replacement were instantaneous (i.e., the message-list route never activated between pressing "Share" and the appearance of the new route), then the keyboard should not reappear, and also the share-sheet action shouldn't need to be followed by the slow exit of the message action sheet.
(This is a milder version of #24, I think; the main symptom of #24 seems to have been fixed in an iOS update.)
If the topic or content input in the compose box was focused when you long-pressed a message, then this sequence is reproducible:
It would be good to eliminate step 4.
The keyboard's entrance and exit are unnecessary and unexpected changes of context, so I'm labeling this as an accessibility issue (
a-a11y
). (The cognitive burden is particularly relevant for our users who are easily distracted, for example. It's also possible that some annoyance or confusion is created for screen-reader users; I haven't tested so I'm not sure.)Here is a recording of the behavior, helpfully provided by @Khader-1 on issue #24:
The text was updated successfully, but these errors were encountered: