UX : Restarting the mobile apps makes PMs disappear for a second or two

[manavmehta]

Restarting the mobile app results in Private Messages being disappeared for a couple of frames showing 'No recent conversations'. Although that exists for a short span, it affects the user experience

OS : Android 8.1, iOS 12.4.5

Clear steps to reproduce the issue (from @ray-kraesig in the chat thread):

1.first, while the app is loading, the banner is present, my existing conversations are shown;

2. The banner disappears, and the PMs display switches to "No recent conversations" for only a frame or two;

3. The conversations come back.

Relevant screenshots:

[gnprice]

Thanks @manavmehta for the report!

In the description you quoted from @ray-kraesig , the "No recent conversations" lasts for just a couple of frames -- which means for less than a tenth of a second.

How long does that situation last for you? Is it also that fast, or does it last longer?

I'm asking partly because you didn't mention having any trouble getting these screenshots. 😉 Doing that would take some excellent timing, like playing a hard video game, if it's as quick for you as Ray reported it is for him.

[gnprice]

Also, here's the diagnosis I posted in that chat thread:

---

@ray-kraesig said:

• then the banner disappears, and the PMs display switches to "No recent conversations" for only a frame or two;

Aha, I think I see why. This was a good clue for pinpointing it. 🙂 It's this sequence in doInitialFetch in fetchActions.js:

  dispatch(initialFetchComplete());
  // ...
  dispatch(fetchPrivateMessages());

And the PM conversations screen relies not on the data we get from /register -- which we've completed fetching by the time we do that initialFetchComplete -- but on the data we get listing specific recent PMs, in fetchPrivateMessages.

And the loading banner (#3901) relies on the flag cleared by initialFetchComplete.

I think the right way to fix this will be to use the recent_private_conversations feature of the server API, described in #3133.

There was a PR for this, #3535. It made substantial progress, but then stalled because the author's summer ended (they were doing GSoC) and they got busy back at school.

[gnprice]

Marking this as blocked on #3133 . When that's fixed, we should come back and look at this issue -- I expect it will have been fixed by the same change that fixes #3133.

[manavmehta]

@gnprice though it was a 'couple' of frames that made it last for me for about a second, so yeah not just one or two frames :P

[rk-for-zulip]

@gnprice though it was a 'couple' of frames that made it last for me for about a second, so yeah not just one or two frames :P

And to confirm, for me it really was "only a frame or two" (i.e., under 100ms). Greg's explanation implies this timespan would be Internet-connection-speed-dependent, though, so this doesn't seem too mysterious a discrepancy.

I think the right way to fix this will be to use the recent_private_conversations feature of the server API, described in #3133.

Agreed on that being the right fix.

If we need something sooner (say, if the visibility of this bug turns out to be higher than we currently think, or #3133 turns out to have unforeseen complications), a reasonable temporary fix would be to show a spinner in place of "No recent conversations" on the PMs screen until fetchPrivateMessages has concluded.

[WesleyAC]

Removing "blocked on other work" label, since #3133 appears to be fixed.

[WesleyAC]

I don't see this anymore, I presume #4392 fixed it. If anyone is still seeing this on a modern server and app, please file a new issue.