Page MenuHomePhabricator

[web] Show a popup when client_version_unsupported
ClosedPublic

Authored by inka on Apr 12 2024, 1:40 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 22, 1:59 AM
Unknown Object (File)
Wed, Nov 20, 1:50 AM
Unknown Object (File)
Sun, Nov 3, 9:11 AM
Unknown Object (File)
Oct 12 2024, 9:21 PM
Unknown Object (File)
Oct 12 2024, 9:21 PM
Unknown Object (File)
Oct 12 2024, 9:21 PM
Unknown Object (File)
Oct 12 2024, 9:21 PM
Unknown Object (File)
Oct 12 2024, 9:21 PM
Subscribers

Details

Summary

issue: [[ https://linear.app/comm/issue/ENG-6128/\[web\]-add-a-ui-element-to-inform-the-user-that-the-client-version-is | ENG-6128 ]]
The text is based on the text shown on native:

'App out of date',
message:
  'Your app version is pretty old, and the server doesn’t know how ' +
  `to speak to it anymore. Please use the ${platformStore} to update!`,

Screenshot 2024-04-11 at 16.47.54.png (1×1 px, 103 KB)

Note that I didn't have any designs for this, so if you think this doesn't look right, let me know!

EDIT:
After some review the modal now looks like this:

image.png (900×1 px, 88 KB)

Test Plan

Tested that if the server sends client_version_unsupported the modal shows up.
Tested that it works on web and desktop

image.png (1×2 px, 1 MB)

Diff Detail

Repository
rCOMM Comm
Branch
inka/client_version_unsupported
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

Adding @ashoat to review copy, and because I didn't have designs

inka edited the summary of this revision. (Show Details)
inka edited the summary of this revision. (Show Details)
inka requested review of this revision.Apr 12 2024, 1:59 AM
ashoat requested changes to this revision.Apr 12 2024, 8:21 AM
ashoat added inline comments.
web/components/version-handler.react.js
20–27 ↗(On Diff #39072)

What is this subheader for? I don't know why it's necessary

I'm guessing it's for indicating which keyserver the message came from, but I think that's confusing to the user. It doesn't really seem to affect what they need to do (refresh the page). Maybe we can remove this?

37–38 ↗(On Diff #39072)

Looks like this copy is mostly from the native version of the same message, so I think it's good.

The only new part is "Please reload the app." We should consider two cases:

  1. Desktop: do users know that it's possible to "reload" the app by using a refresh keyboard shortcut?
  2. Web: will users be confused about "reloading" the "app", as opposed to "refreshing" a "page"?

Not a huge deal, and I'm not sure we need to do much here... most users will probably figure it out. If the desktop users end up just closing and restarting the app, that should work too I think.

This revision now requires changes to proceed.Apr 12 2024, 8:21 AM
web/components/version-handler.react.js
20–27 ↗(On Diff #39072)

Yes, this subheader was supposed to inform the user which server sent the error. But I can remove it if it is unnecessary.

37–38 ↗(On Diff #39072)

How about Please reload the app for desktop and Please refresh the page for web?
I feel like the users will know to either close and reopen or use the shortcut on desktop.

inka edited the summary of this revision. (Show Details)EditedApr 15 2024, 2:37 AM

Now the modal looks like this:

image.png (900×1 px, 68 KB)

Can't we simply reload the page when the client version is unsupported?

Can't we simply reload the page when the client version is unsupported?

I don't know if we want to be forcing users to have the page reloaded if some secondary keyserver sends an error... This would for example delete an entry they are creating

Accepting, but I have some change requests inline. If anything is unclear, please re-request review :)

How about Please reload the app for desktop and Please refresh the page for web?
I feel like the users will know to either close and reopen or use the shortcut on desktop.

Sounds good to me! Can you amend the Test Plan to confirm that you've tested both?

I don't know if we want to be forcing users to have the page reloaded if some secondary keyserver sends an error... This would for example delete an entry they are creating

I agree

web/components/version-handler.react.js
48–50 ↗(On Diff #39108)

This seems risky... you appear to be pushing a new modal every time this effect runs, which I think could lead to multiple of the same modal being pushed. Can you instead change the code so you only push the modal when the change appears? I think you'll need a prevConnectionIssueRef

63–65 ↗(On Diff #39108)

Can this be memoized on keyserverIDs?

This revision is now accepted and ready to land.Apr 15 2024, 7:02 AM

Memoize list of components, only display the alert once for each keyserver

inka requested review of this revision.Apr 15 2024, 9:13 AM

Requesting review because now:

  1. We can still see this modal more than once - for other keyservers. Is this that we want??
  2. For the auth keyserver, the user is logged out. If they dismiss the modal, but ignore it and log in, they will be logged out and will NOT see the modal again. Is this ok or should I make logging in reset this state?
In D11643#335050, @inka wrote:

Requesting review because now:

  1. We can still see this modal more than once - for other keyservers. Is this that we want??
  2. For the auth keyserver, the user is logged out. If they dismiss the modal, but ignore it and log in, they will be logged out and will NOT see the modal again. Is this ok or should I make logging in reset this state?
  1. Hmm... ideally, no. But I'm not sure how complicated it would be to address this, and whether it should be prioritized.
  2. A bit confused about the scenario you describe. How is the user able to log in after being logged out, if they can't auth with the authoritative keyserver? Doesn't the authoritative keyserver make the version check during auth?
web/components/version-handler.react.js
54 ↗(On Diff #39129)

I think this code is incorrect. You're only updating prevConnectionIssueRef when connectionIssue === 'client_version_unsupported', so prevConnectionIssueRef.current will always be 'client_version_unsupported' after the first call

A bit confused about the scenario you describe. How is the user able to log in after being logged out, if they can't auth with the authoritative keyserver? Doesn't the authoritative keyserver make the version check during auth?

Oh, you are right, sorry. My testing method didn't correctly reflect this. So this is not an issue

web/components/version-handler.react.js
54 ↗(On Diff #39129)

Do we want to show the modal again if somehow connectionIssue changes from client_version_unsupported to something else and then back?
Don't we want to show it one time?

ashoat added inline comments.
web/components/version-handler.react.js
43

Let's rename this to hasShownModalRef

54 ↗(On Diff #39129)

Ah, I see what you're saying. We can keep your code, but let's rename the ref to more accurately reflect what it's actually tracking

This revision is now accepted and ready to land.Apr 16 2024, 4:45 AM