DataViews: async loading controls foil first focus on mount #75540

Activity

1. stokesman

   added

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   [Package] DataViews/packages/dataviews/packages/dataviews

   on Feb 13, 2026
2. nirav7707 commented on Feb 17, 2026

   

   nirav7707

   on Feb 17, 2026

   Contributor

   More actions

   @stokesman As per my research, it looks like this is happening due to the async operation. When the click event is triggered, the authors are fetched through an API call. At that moment, the control is not yet fully initialised, so the focus falls back from firstInputElement to firstElement. As a result, the first time the dialog opens, the focus goes to the close button.

   👀React with 👀1Reacted by Mayank Tripathi
3. Mayank-Tripathi32 commented on Feb 18, 2026

   

   Mayank-Tripathi32

   on Feb 18, 2026

   Member

   More actions

   the control is not yet fully initialised, so the focus falls back from firstInputElement to firstElement. As a result, the first time the dialog opens, the focus goes to the close button.

   We could manually trigger a refocus once the fetching completes or maybe a loading state?
4. stokesman commented on Feb 18, 2026

   

   stokesman

   on Feb 18, 2026

   ContributorAuthor

   More actions

   so the focus falls back from firstInputElement to firstElement

   Yes and thanks to that this issue can probably be considered a potential enhancement instead of a bug. I'd been thinking this since I made the issue and now I’ll change it.

   We could manually trigger a refocus once the fetching completes or maybe a loading state?

   I assume all the async controls do have a loading state – as the select control shown in the screen recording has:
   

   gutenberg/packages/dataviews/src/components/dataform-controls/select.tsx

   Lines 41 to 43 in c4e4fac

   	if ( isLoading ) {
   	return <Spinner />;
   	}

   I’d doubt that focus should be moved to the control if loading takes longer than ~200 milliseconds. With that in mind, my current thought is to make the useFocusOnMount hook have an option that makes it retry until a maximum timeout has elapsed before doing the fallback. Whatever the solution, it seems low priority.
5. stokesman

   added

   [Type] EnhancementA suggestion for improvement.A suggestion for improvement.

   [Priority] LowUsed to indicate that the issue at hand isn't a top priority to address and can be handled laterUsed to indicate that the issue at hand isn't a top priority to address and can be handled later

   and removed

   [Type] BugAn existing feature does not function as intendedAn existing feature does not function as intended

   on Feb 18, 2026
6. github-actions

   added

   [Status] In ProgressTracking issues with work in progressTracking issues with work in progress

   on Feb 27, 2026