Don't junk the server URL if subsequent connection failed #789
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So currently a failure to connect to a previously saved server will present an empty server connect page again.
But this sucks, because either the server or user's internet connection might be down, and we know the server should be okay since it worked before. So this fills out the address text input with the currently saved server, this way the user can easily retry the connection without being frustrated that the server URL was junked and they gotta pull it out of memory and re-type to reconnect.
Now the way I understand it, it was never junked from the local storage to begin with, so technically they'd be able to reconnect by restarting the app too? But nobody would ever guess that if they see empty connection form, they'd assume all was reset.
Also it is my sincere hope that in such a situation local storage in terms of login data won't be junked either hopefully, but even if it does, this PR is still going to make it all a bit less of PITA for users