Sign-in: a refused first sign-in stays on the sign-in screen with its error #89

Closed

ryoitsu69 wants to merge 0 commits from ryoitsu69/anotherim-js:fix/sign-in-refusal-stays into develop

ryoitsu69 commented

2026-11-06 22:06:30 +00:00

Contributor

After a first sign-in the server refuses, the error is not seen: the chats flash for a moment and the welcome screen comes back empty, with no message.

Cause

The error lives in <aim-signin-card>, inside <aim-welcome>. On a refusal the card calls accounts.remove and sends sign-in-failed, and the shell clears pendingSignIn. But accounts.remove only asks: the row leaves with account <Removed> and the next account list. While the list names the account, welcomePhase says done, so the shell takes <aim-welcome> down with the card and its error, and a new empty one follows when the row goes.

The order cannot be relied on either. Against a local ejabberd the refusal left tackyd-json 40 ms after its answer to account list on a first attempt and 5 ms after on later ones, and Store.#loadAccounts awaits more before the page has that answer, so the page can hear the refusal before the list names the account. A version of this fix that held the screen until the row left worked on the first attempt only.

Fix

The shell keeps the address from sign-in-failed as refusedSignIn, and #welcomePhase holds the screen while the list names no other account (s.accounts.every(...)), whether the row comes before the refusal or after it. The mark goes at the next sign-in-pending, or when that address connects another way (onConnected), a code from another device, say. The add-account sheet is not touched: its card's events do not pass through <aim-welcome>.

One case stays open, from reading the code, not run: after a refusal, a backup or a code that brings back only that same address keeps the welcome screen up until it connects. If it cannot connect, for example offline, the screen stays until a restart or a new sign-in.

Testing

welcome-shell.test.ts gains three tests: refusals in a row, a refusal heard before the list names the account, and a refused address connecting another way. All three fail on 5f1ef7e8. The mock connects every enabled account, even a refused one, so they drop that event.
On this branch, make test-ui check test-shell webkit-smoke: 5146 passed, 8 skipped, check clean, 442 shell tests passed, smoke 9575 checks, 0 failed.
On a local ejabberd 26.09 (anotherim-server b9e675dd), an AppImage of this fix on 5f1ef7e8, before the rebase:
- The error stayed over the form through 11 refused sign-ins in a row on the welcome screen, on three addresses. The server's log has each one.
- A wrong password and then the right one on the same address opened the chats.

Not run: Android.

🤖 Generated with Claude Code

After a first sign-in the server refuses, the error is not seen: the chats flash for a moment and the welcome screen comes back empty, with no message. ## Cause The error lives in `<aim-signin-card>`, inside `<aim-welcome>`. On a refusal the card calls `accounts.remove` and sends `sign-in-failed`, and the shell clears `pendingSignIn`. But `accounts.remove` only asks: the row leaves with `account <Removed>` and the next `account list`. While the list names the account, `welcomePhase` says `done`, so the shell takes `<aim-welcome>` down with the card and its error, and a new empty one follows when the row goes. The order cannot be relied on either. Against a local ejabberd the refusal left `tackyd-json` 40 ms after its answer to `account list` on a first attempt and 5 ms after on later ones, and `Store.#loadAccounts` awaits more before the page has that answer, so the page can hear the refusal before the list names the account. A version of this fix that held the screen until the row left worked on the first attempt only. ## Fix The shell keeps the address from `sign-in-failed` as `refusedSignIn`, and `#welcomePhase` holds the screen while the list names no other account (`s.accounts.every(...)`), whether the row comes before the refusal or after it. The mark goes at the next `sign-in-pending`, or when that address connects another way (`onConnected`), a code from another device, say. The add-account sheet is not touched: its card's events do not pass through `<aim-welcome>`. One case stays open, from reading the code, not run: after a refusal, a backup or a code that brings back only that same address keeps the welcome screen up until it connects. If it cannot connect, for example offline, the screen stays until a restart or a new sign-in. ## Testing - `welcome-shell.test.ts` gains three tests: refusals in a row, a refusal heard before the list names the account, and a refused address connecting another way. All three fail on 5f1ef7e8. The mock connects every enabled account, even a refused one, so they drop that event. - On this branch, `make test-ui check test-shell webkit-smoke`: 5146 passed, 8 skipped, `check` clean, 442 shell tests passed, smoke 9575 checks, 0 failed. - On a local ejabberd 26.09 (anotherim-server b9e675dd), an AppImage of this fix on 5f1ef7e8, before the rebase: - The error stayed over the form through 11 refused sign-ins in a row on the welcome screen, on three addresses. The server's log has each one. - A wrong password and then the right one on the same address opened the chats. Not run: Android. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

ryoitsu69 added 1 commit

2026-11-06 22:06:30 +00:00

Sign-in: a refused first sign-in stays on the sign-in screen with its error. sign-in-failed let go of pendingSignIn while the account was still listed, since accounts.remove only asks and the row leaves with <Removed> and the next account list. So welcomePhase counted it, the shell took <aim-welcome> down with the card and its error, the chats flashed, and an empty welcome came back with no message. Holding the screen until the row leaves is not enough, because the order is not fixed: against a local ejabberd the refusal left libtacky's daemon 40 ms after its answer to account list on a first attempt and only 5 ms after on later ones, and the page reads that answer later still, so it can hear the refusal before the list names the account. The shell now keeps the address as refusedSignIn, no account to the count whenever the list names it, until the next sign-in or until that address connects by another way in. welcome-shell.test.ts takes refusals in a row, a refusal heard before the list names the account, and a refused address connecting by another way; all three fail on 5f1ef7e8. On a local ejabberd 26.09 a build with this change kept the error through 11 refused sign-ins in a row on the first-run screen. CHANGELOG under Unreleased. 52672b934a

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ann referenced this pull request from a commit

2026-11-07 22:42:32 +00:00

0.8.0-rc7, on libtacky v1.2.1 (8919dc12): 0.8.0-rc6 with the modern-only encryption switch per chat, Privacy's "Keep metadata for legacy clients", Who sees my profile and pictures fitted to 72 KiB (feat/profile-visibility), the account password changed at the server (#94), the sign-in fixes (#89, #90), status colours as in Set status (#91), a menu for picked messages (#93), one playback for a full-screen video (#87), reactions as chips inside the bubble (feat/reactions-chips), local delete and Clear history, the stranger's dropped message told (#85), the presence dot back beside a network badge, one Experimental settings card, Copy image on Linux off the main thread and the XML_LOG test build; libtacky pinned to the v1.2.1 tag with the generated API regenerated; made the seventh release candidate: version 0.8.0-rc7 in the UI package and its lock, tauri.conf.json, Cargo.toml and Cargo.lock and the README's version line, Android versionCode 8011; a compact 0.8.0-rc7 CHANGELOG entry (with a From libtacky 1.2.1 bullet) in place of the Unreleased bullets; the metainfo's development release 0.8.0~rc7 (appstreamcli validate --no-net passes). docs/macos.md stays at the last Mac release. README's tables measured again on this tree: 114,546 lines of code and 118,964 of tests (the change since 0.8.0-rc6 counted by the same rules), the UI's 68,842 of 70,448 lines (97.7%, 90.7% of branches), the shell's 12,588 of 13,319 source lines (94.5%), the Kotlin's 4,536 of 4,795 (94.6%), the worker's 872 of 872. Gates: on c4b08323 (the pin) make check STRICT=1 clean, make build, make test-shell 455 in 56 modules, make test-worker green, make release-check passed (no advisory), the WebKit smoke 10,035 checks, 0 failed; before the pin (shell and Kotlin unchanged by it) on 16a94364 the Android JVM tests free 640 and gms 643 passed and cargo check of the shell for x86_64-pc-windows-gnu clean, on bf87e9f7 (its clipboard test brought to Linux's GTK copy) make coverage-shell-all 484 passed; on cc3d1545 (with feat/reactions-chips, UI only) make check STRICT=1 clean (2,500 strings in all five catalogues, seven obsolete), make test-ui 5,246 passed, 8 skipped (444 files), the WebKit smoke 982 screens, 10,103 checks, 0 failed with SMOKE_JOBS=16.

ann commented

2026-11-07 23:14:08 +00:00

Owner

Merged (PR #89) and in anotherim-js 0.8.0-rc7 (https://dev.another.im/another-im/anotherim-js/releases/tag/v0.8.0-rc7): a refused first sign-in now keeps the sign-in screen and its error instead of flashing an empty welcome screen. The shell used to drop pendingSignIn as soon as the account's removal was asked for, but the removal and the server's refusal did not always arrive in that order; the screen now holds the address as a pending refusal until the account list actually drops it or it connects another way, so the error is shown whichever order the two answers come in.

Please check with 0.8.0-rc7 or newer.

Merged (PR #89) and in anotherim-js 0.8.0-rc7 (https://dev.another.im/another-im/anotherim-js/releases/tag/v0.8.0-rc7): a refused first sign-in now keeps the sign-in screen and its error instead of flashing an empty welcome screen. The shell used to drop `pendingSignIn` as soon as the account's removal was asked for, but the removal and the server's refusal did not always arrive in that order; the screen now holds the address as a pending refusal until the account list actually drops it or it connects another way, so the error is shown whichever order the two answers come in. Please check with 0.8.0-rc7 or newer.

ryoitsu69 closed this pull request

2026-11-09 02:31:34 +00:00