-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ui: Incorrect null-check operator in _LoadingPlaceholderPageState.build
#1219
Milestone
Comments
chrisbobbe
added a commit
that referenced
this issue
Dec 27, 2024
PIG208
added a commit
to PIG208/zulip-flutter
that referenced
this issue
Dec 30, 2024
We could pass realmUrl when initializing the `_LoadingPlaceholderPage`, but that will still require a check for the existence of the account. The loading page will be blank when the account does not exist. The user can't easily reach this page because they can only logout from `ChooseAccountPage`, until we start invalidating API keys. Even then, they will only see the blank page briefly before getting navigated, so we should not show any text at all. Fixes: zulip#1219 Signed-off-by: Zixuan James Li <[email protected]>
PIG208
added a commit
to PIG208/zulip-flutter
that referenced
this issue
Jan 2, 2025
We could pass realmUrl when initializing the `_LoadingPlaceholderPage`, but that will still require a check for the existence of the account. The loading page will be blank when the account does not exist. The user can't easily reach this page because they can only logout from `ChooseAccountPage`, until we start invalidating API keys. Even then, they will only see the blank page briefly before getting navigated, so we should not show any text at all. Fixes: zulip#1219 Signed-off-by: Zixuan James Li <[email protected]>
PIG208
added a commit
to PIG208/zulip-flutter
that referenced
this issue
Jan 2, 2025
We could pass realmUrl when initializing the `_LoadingPlaceholderPage`, but that will still require a check for the existence of the account. The loading page will be blank when the account does not exist. The user can't easily reach this page because they can only logout from `ChooseAccountPage`, until we start invalidating API keys. Even then, they will only see the blank page briefly before getting navigated, so we should not show any text at all. Fixes: zulip#1219 Signed-off-by: Zixuan James Li <[email protected]>
PIG208
added a commit
to PIG208/zulip-flutter
that referenced
this issue
Jan 2, 2025
We could pass realmUrl when initializing the `_LoadingPlaceholderPage`, but that will still require a check for the existence of the account. The loading page will be blank when the account does not exist. The user can't easily reach this page because they can only logout from `ChooseAccountPage`, until we start invalidating API keys. Even then, they will only see the blank page briefly before getting navigated, so we should not show any text at all. Fixes: zulip#1219 Signed-off-by: Zixuan James Li <[email protected]>
PIG208
added a commit
to PIG208/zulip-flutter
that referenced
this issue
Jan 3, 2025
We could pass realmUrl when initializing the `_LoadingPlaceholderPage`, but that will still require a check for the existence of the account. The loading page will be blank when the account does not exist. The user can't easily reach this page because they can only logout from `ChooseAccountPage`, until we start invalidating API keys. Even then, they will only see the blank page briefly before getting navigated, so we should not show any text at all. Fixes: zulip#1219 Signed-off-by: Zixuan James Li <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To reproduce:
This is a latent bug introduced in a97ac42 (fyi @PIG208). This widget shouldn't assume that an account for its
accountId
param exists; in particular, it won't exist in the short period after the account is removed from the database (for logout) and beforerouteToRemoveOnLogout
is processed in a post-frame callback.I see two plausible fixes:
accountId
param and pass…hmm, I guess arealmUrl
param, for the "try another account" message. Or:accountId
param but give it dartdoc with a reminder that the corresponding account might not exist, saying why.In either case we should add a test that would fail before the fix but passes after it.
The text was updated successfully, but these errors were encountered: