fix(extension): stop the new tab page stealing the address bar's caret

[tsahimatsliah]

Changes

Fixes a long-standing, roughly-once-a-day bug on the extension's new tab page: you click Chrome's address bar, the caret lands there, and typing does nothing. The page scrolls and clicks normally throughout. Opening any post modal clears it.

That last detail is the tell. The cause is a focus steal: something in the page waits for the window to lose focus — which is exactly what clicking the address bar is — and then calls focus() on one of its own elements, dragging the caret back into the page. Everything typed afterwards goes into the page, where nothing is listening.

The clearest source is react-modal's global focus manager (react-modal@3.16.3, lib/helpers/focusManager.js):

• handleBlur arms a module-global needToFocus flag on every window blur.
• handleFocus then pulls focus into modalElement on the next focus event in the document, with no check that the page actually holds the keyboard.
• teardownScopedFocus never removes that listener — it is registered on document in the capture phase and removed without the capture flag, so removeEventListener doesn't match.
• Teardown is skipped entirely when a modal unmounts before its isOpen state commits (componentWillUnmount guards on this.state.isOpen), leaving modalElement pointing at a node no longer on screen with the pull still armed.

That is also why opening and closing a card's modal fixes it: afterClose finally reaches teardownScopedFocus(), which nulls modalElement and disarms the whole thing.

The fix

preventFocusSteal() runs at the top of the new tab entry, before React and before any dependency registers its own focus bookkeeping. It drops programmatic focus() while document.hasFocus() is false — true in exactly the moments the keyboard belongs to browser chrome (address bar, devtools, another window) rather than to us.

User gestures are unaffected: clicking or tabbing into the page hands focus over before any handler runs, so hasFocus() is already true by then.

Why the class and not just react-modal

Two reasons worth a reviewer's attention:

1. This bug shows up about once a day and I could not reproduce it on demand, so I could not prove a react-modal-specific patch actually fixed it.
2. react-modal is not the only candidate. Radix focus scopes (FocusScope's MutationObserver refocuses its container when document.activeElement === document.body, which is the state while the address bar has focus) and the embedded ad measurement frames have their own variants of the same move.

Refusing the move once, in one place, covers all of them. The tradeoff is a monkey-patch on HTMLElement.prototype.focus, scoped to the new tab entry only — not the webapp, not the companion.

Known gap: if the culprit turns out to be inside the ad measurement iframe, that is a separate origin and this guard cannot reach it. The tell would be the bug recurring with nothing logged. The same guard would then need to go into the measurement frame page.

Diagnostics

Outside production the guard logs a warning with a stack trace every time it blocks a steal, so the culprit names itself if it ever fires.

Events

No new tracking events.

Experiment

No new experiments.

Manual Testing

Extension only — the webapp and companion entries are untouched.

• Have you done sanity checks in the extension?
• Does this not break anything in companion? (companion entry not touched)

Verified: 3 new unit tests, full extension suite passes (55 tests, 7 suites), lint clean, production build succeeds. The one pre-existing tsc error in ShortcutLinks.spec.tsx is present on main and unrelated.

Note

Opened as a draft. The only real verification for a once-a-day bug is running a dev build for a few days and confirming it does not recur — and that the guard's dev warning either names a culprit or stays quiet.

🤖 Generated with Claude Code

Preview domain

https://newtab-focus-steal-dailydotdev.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
daily-webapp	Ready	Preview	Sep 4, 2026 3:10pm UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
storybook	Ignored		Sep 4, 2026 3:10pm UTC