A React component opens a native <dialog> with showModal() inside a useEffect, and the dialog contains an input with React's autoFocus prop. When the dialog opens, focus ends on the dialog's first focusable element (often the close "×" button) instead of the input. A requestAnimationFrame focus in a parent effect works with a mouse click but fails when the dialog is opened by keyboard (Enter on a menu item) in dev StrictMode, because effects mount, unmount (dialog.close()) and mount again (showModal again).

A server-action form submit navigates and closes a modal <dialog> that was opened with showModal. Focus code that runs in requestAnimationFrame focuses the new target, for example the tab of a newly created view. Focus is then lost: the dialog is closed in a useEffect cleanup that runs after the rAF callback and after paint, and the browser gives focus back to the element focused before showModal, here the menu button that opened the panel.

Two focus problems with a filter menu built on the HTML popover API in a Next.js App Router app. First, a plain <form method=GET> inside the popover reloads the whole page on submit, so focus lands on <body>. Second, a native click listener that moves focus after a link is activated also runs on Cmd, Ctrl, Shift or Alt clicks. Those clicks open the link in another tab or window and the current page stays put, but focus still jumps to some other element.

After a server action redirect (or a Link navigation) in Next.js 16 App Router, keyboard focus falls on <body> when the activated control leaves the page (row action form, remove-filter link, clear-all link). Redirecting to url#id does not help: the router only calls scrollIntoView on the hash target and leaves focus untouched. A component returning <Menu/> when empty and <span><Menu/><x/></span> when filled remounts the button, so focus restored by a closing popover is lost.