Fix: "Add another account" button now navigates to sign-in page#208
Merged
Conversation
- Fixed premature redirect-to-home when authenticated user visits /auth/login?switchAccount=1, caused by searchParams being momentarily null during Next.js client-side navigation - Added event.preventDefault/stopPropagation to addAnotherAccount handler, consistent with other interactive buttons in the dropdown - Added informational banner on login page when ?switchAccount=1 is present - Extracted shared hasSearchParam() utility to avoid duplicating the searchParams null-fallback logic Agent-Logs-Url: https://github.com/WeWriteApp/WeWrite/sessions/a0477169-9657-4fc2-8de4-c3efe4606891 Co-authored-by: sirjamesgray <16139439+sirjamesgray@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Copilot created this pull request from a session on behalf of
sirjamesgray
May 11, 2026 02:14
View session
sirjamesgray
approved these changes
May 11, 2026
- Changed addAnotherAccount to use window.location.href (full page reload) instead of router.push (client-side nav) to prevent premature redirect. With router.push the AuthProvider stays settled (isLoading=false) so the login form's redirect guard fires before useSearchParams has the new URL. - Updated hasSearchParam to always check window.location.search first (as the authoritative source), then fall back to the searchParams object. Previously only fell back to window.location when searchParams was null, missing the stale-but-non-null case during client-side navigation. Agent-Logs-Url: https://github.com/WeWriteApp/WeWrite/sessions/39dca12d-9ffe-4242-9469-01ba643071e8 Co-authored-by: sirjamesgray <16139439+sirjamesgray@users.noreply.github.com>
sirjamesgray
approved these changes
May 11, 2026
There was a problem hiding this comment.
Pull request overview
Resolves an account-switching flow bug where clicking “Add another account” could immediately bounce an already-authenticated user away from the login page due to stale useSearchParams() during client-side navigation.
Changes:
- Added a
hasSearchParamhelper to detect query flags usingwindow.location.searchas a more reliable source during navigation. - Updated the login redirect guard to use
hasSearchParamso authenticated users aren’t redirected whenswitchAccountis present. - Changed “Add another account” navigation to
window.location.hrefto force a full reload and avoid auth/searchParams race conditions; also simplified the click handler wiring.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| app/utils/searchParams.ts | Introduces hasSearchParam helper for safer query detection during client-side navigation. |
| app/components/layout/MobileAccountMenu.tsx | Forces full-page navigation for add-account flow to avoid stale params/auth state issues. |
| app/components/forms/login-form.tsx | Updates authenticated-redirect logic to honor switchAccount via the new helper. |
| app/auth/login/page.tsx | Shows an add-account banner when switchAccount is present using the new helper. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+2
to
+26
| * Returns true if the given key exists in the provided Next.js searchParams object | ||
| * OR in the current browser URL. | ||
| * | ||
| * Two failure modes are handled: | ||
| * 1. `useSearchParams()` returns null before Next.js has resolved the URL during | ||
| * client-side navigation — the window.location fallback covers this case. | ||
| * 2. `useSearchParams()` returns a non-null but *stale* object (from the previous | ||
| * page) when the component mounts before the router has flushed the new params — | ||
| * the window.location fallback is always checked regardless. | ||
| */ | ||
| export function hasSearchParam( | ||
| searchParams: { has(key: string): boolean } | null | undefined, | ||
| key: string | ||
| ): boolean { | ||
| // Always check window.location first — it reflects the address bar immediately | ||
| // and is immune to any stale searchParams object from the previous render. | ||
| if (typeof window !== 'undefined') { | ||
| if (new URLSearchParams(window.location.search).has(key)) { | ||
| return true; | ||
| } | ||
| } | ||
| // Fall back to the searchParams object (may be null/stale on client-side nav) | ||
| if (searchParams != null) { | ||
| return searchParams.has(key); | ||
| } |
This file contains hidden or 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.
searchParamsduring client-side navigation causes premature redirectaddAnotherAccountto usewindow.location.href(full page load) instead ofrouter.pushhasSearchParamto always checkwindow.location.searchfirst (OR logic, not only-if-null)addAnotherAccountdirectly (code review feedback)