fix: update existing tab state when openNew/openCurrent called with explicit state#4134
fix: update existing tab state when openNew/openCurrent called with explicit state#4134devin-ai-integration[bot] wants to merge 1 commit intomainfrom
Conversation
…xplicit state
When openNew or openCurrent is called with an explicit state (e.g.,
{ type: 'ai', state: { tab: 'intelligence' } }), and an existing tab
of the same type is found, the existing tab's state is now updated
with the requested state instead of being ignored.
Previously, the existing tab was simply activated without updating its
state, so calling openNew({ type: 'ai', state: { tab: 'intelligence' } })
when the AI tab was already open on the 'templates' sub-tab would keep
showing templates instead of switching to intelligence.
Co-Authored-By: yujonglee <yujonglee.dev@gmail.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
✅ Deploy Preview for hyprnote-storybook canceled.
|
✅ Deploy Preview for hyprnote canceled.
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| nextTabs = tabs.map((t) => | ||
| isSameTab(t, existingTab!) ? currentTab : { ...t, active: false }, | ||
| ); | ||
| return { tabs: nextTabs, currentTab, history } as Partial<T>; |
There was a problem hiding this comment.
🚩 State update on existing tab bypasses history tracking
When an existing tab is found and its state is updated (the shouldUpdateState branch at line 287-298), the function returns { tabs: nextTabs, currentTab, history } at line 299 — passing the original history map unchanged. This means navigating to an already-open tab with a new state (e.g., openNew({ type: 'ai', state: { tab: 'templates' } }) when an ai tab is already open with { tab: 'intelligence' }) will silently update the tab's state without creating a history entry. The user cannot "go back" to the previous state of that tab.
This is the same behavior as before this PR (the old code also returned history unchanged for existing tabs), so it's not a regression. However, it's worth noting that the new state-update feature amplifies the impact of this pre-existing design choice — previously, reopening an existing tab was a no-op on state, so skipping history was fine. Now that state actually changes, skipping history means state transitions are not reversible via back/forward navigation.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
fix: update existing tab state when openNew called with explicit state
Summary
When
openNew({ type: "ai", state: { tab: "intelligence" } })is called and an AI tab is already open (e.g., on the "templates" sub-tab), the existing tab was simply activated without updating its state. This meant the user would see whichever sub-tab was previously open instead of the requested one.The fix: in
openTab, when an existing matching tab is found and the caller provided an explicitstate, the existing tab's state is now replaced with the requested state before activation.Review & Testing Checklist for Human
TabInput, it will be lost.as anycast:(tabWithDefaults as any).statebypasses type checking due to theTabunion type. Worth a glance to confirm safety.openNew({ type: "ai", state: { tab: "intelligence" } })(e.g., from a config-error prompt) → verify the AI tab now shows the Intelligence/LLM sub-tab.Notes