[X] I checked for similar issues, but could not find any. I also checked the closed issues. I could not contribute additional information to any existing issue.
[X] I will take the time to fill in all the required fields. I know that the bug report may be dismissed otherwise due to lack of information.
Feature description
Currently, whenever an error occurs (or the authorization process succeeds, but the latter is not really a problem), the OAuth object replies one last time and then, the server is closed, i.e., new connections are no longer accepted.
From a UX perspective, this makes little sense. Users trying to reload the page will see a "server unavailable" or "connection refused" kind of message, which is pretty unexpected, especially since we merged #10011.
Proposed solution
The integrated webserver should run until the OAuth object is cleaned up. With the current setup wizard and login required dialog system, the cleanup happens on a user interaction only. The user will be notified that the login succeeded, therefore won't be surprised when the server is closed then. As long as the setup wizard or the login required dialog are displayed, the webserver will continue to run, and users can refresh pages etc.
Alternative solutions you considered
We could also start a webserver on some (randomly generated) port right from the beginning and use it to handle all user interaction. I don't think that this is necessary, though.
Additional context
We should think about offering a "retry" button right in the web browser as well. Also, we should probably inform the user right on the web page that the current tab can be closed not only upon success, but also in case of an error or when the user closes the login required dialog or the setup wizard.
TheOneRing
commented
1 year ago
Pre-submission Checks
Feature description
Currently, whenever an error occurs (or the authorization process succeeds, but the latter is not really a problem), the
OAuthobject replies one last time and then, the server is closed, i.e., new connections are no longer accepted.From a UX perspective, this makes little sense. Users trying to reload the page will see a "server unavailable" or "connection refused" kind of message, which is pretty unexpected, especially since we merged #10011.
Proposed solution
The integrated webserver should run until the
OAuthobject is cleaned up. With the current setup wizard and login required dialog system, the cleanup happens on a user interaction only. The user will be notified that the login succeeded, therefore won't be surprised when the server is closed then. As long as the setup wizard or the login required dialog are displayed, the webserver will continue to run, and users can refresh pages etc.Alternative solutions you considered
We could also start a webserver on some (randomly generated) port right from the beginning and use it to handle all user interaction. I don't think that this is necessary, though.
Additional context
We should think about offering a "retry" button right in the web browser as well. Also, we should probably inform the user right on the web page that the current tab can be closed not only upon success, but also in case of an error or when the user closes the login required dialog or the setup wizard.