Fix focusmanager index corruption

[ZainabTravadi]

Description

Fixes a bug in FocusManager where dynamically registering a new focusable could unexpectedly change the currently focused widget.

When the internal focusable list is reordered by tabIndex, _currentIndex could become stale and point to a different widget. This change preserves focus identity across registration reordering and adds a regression test covering the scenario.

Related Issue

Closes #1759

Which package(s)?

@termuijs/core

Type of Change

• 🐛 Bug fix (type:bug)
• 🧪 Tests (type:testing)

Checklist

• ⭐ You starred the repo. The needs-star check blocks your merge otherwise.
• Tests pass locally: bun vitest run
• Build passes: bun run build
• Typecheck passes: bun run typecheck
• You read CONTRIBUTING.md.
• Your PR title follows type: short description.
• Widget state mutators call markDirty() (if your change affects rendering).
• No new any types without an inline comment explaining why.
• No unrelated refactors bundled into this PR.

GSSoC 2026 Participation

• You are a GSSoC 2026 contributor.
• Your GSSoC profile: https://gssoc.girlscript.org/profile/3652c85d-e890-41f5-a48f-584ed0a7f209

Screenshots / Recordings (UI changes)

N/A

Notes for the Reviewer

Reproduction

1. Register focusable A (tabIndex = 10)
2. Register focusable B (tabIndex = 20)
3. Focus B
4. Register focusable C (tabIndex = 5)

Before this change:

• Focusables reorder to [C, A, B]
• _currentIndex remains unchanged
• Focus unexpectedly changes from B to A

After this change:

• Focusables still reorder correctly
• _currentIndex is updated to track the same focused widget
• Focus remains on B

A regression test has been added to verify that dynamically registering a focusable that sorts before the currently focused widget does not change focus unexpectedly.

[coderabbitai]

Warning

Review limit reached

@ZainabTravadi, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 3 minutes and 28 seconds. Learn how PR review limits work.

To continue reviewing without waiting, enable usage-based billing in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 24541b8f-0c44-47a5-8b98-ebf27e940b9b

📥 Commits

Reviewing files that changed from the base of the PR and between 35c2213 and bd94d0f.

📒 Files selected for processing (2)

• packages/core/src/events/FocusManager.test.ts
• packages/core/src/events/FocusManager.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}