From 8f4150605449efe909822d8b20fe529d85851afe Mon Sep 17 00:00:00 2001
From: Ruslan Lesiutin <28902667+hoxyq@users.noreply.github.com>
Date: Thu, 12 Mar 2026 14:19:21 -0700
Subject: [PATCH 1/2] [DevTools] fix: don't show empty suspended by section
(#36011)
The potential paddings and margins for the empty block are already
handled via CSS selectors.
---
.../devtools/views/Components/InspectedElementSuspendedBy.js | 3 +++
1 file changed, 3 insertions(+)
diff --git a/packages/react-devtools-shared/src/devtools/views/Components/InspectedElementSuspendedBy.js b/packages/react-devtools-shared/src/devtools/views/Components/InspectedElementSuspendedBy.js
index 50186f47b215..ffcdd7df0ca8 100644
--- a/packages/react-devtools-shared/src/devtools/views/Components/InspectedElementSuspendedBy.js
+++ b/packages/react-devtools-shared/src/devtools/views/Components/InspectedElementSuspendedBy.js
@@ -584,6 +584,9 @@ export default function InspectedElementSuspendedBy({
break;
}
+ if (groups.length === 0) {
+ return null;
+ }
return (
From c80a07509582daadf275f36ffe7a88c3b12e9db4 Mon Sep 17 00:00:00 2001
From: Jack Pope
Date: Thu, 12 Mar 2026 14:36:28 -0700
Subject: [PATCH 2/2] Fix focus set for delegated and already focused elements
(#36010)
I found two focus bugs when working on documentation for Fragment Refs.
1) If an element delegates focus handling, it will return false from
setFocusIfFocusable even though a focus event has occured on a different
element. The fix for this is a document level event listener rather than
only listening on the current element.
For example, if you have a form with multiple nested label>inputs.
Calling focus on the label will focus its input but not fire an event on
the label. setFocusIfFocusable returns false and you end up continuing
to attempt focus down the form tree.
2) If an element is already focused, setFocusIfFocusable will return
false. The fix for this is checking the document's activeElement with an
early return.
In the same form example, if the first input is already focused and you
call fragmentInstance.focus() at the form level, the second input would
end up getting focused since the focus event on the first is not
triggered.
---
.../src/client/ReactFiberConfigDOM.js | 18 +++-
.../__tests__/ReactDOMFragmentRefs-test.js | 96 +++++++++++++++++++
2 files changed, 111 insertions(+), 3 deletions(-)
diff --git a/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js b/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js
index 4cb4e8e4273a..727ec694bbf7 100644
--- a/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js
+++ b/packages/react-dom-bindings/src/client/ReactFiberConfigDOM.js
@@ -4520,18 +4520,30 @@ export function setFocusIfFocusable(
//
// We could compare the node to document.activeElement after focus,
// but this would not handle the case where application code managed focus to automatically blur.
+ const element = ((node: any): HTMLElement);
+
+ // If this element is already the active element, it's focusable and already
+ // focused. Calling .focus() on it would be a no-op (no focus event fires),
+ // so we short-circuit here.
+ if (element.ownerDocument.activeElement === element) {
+ return true;
+ }
+
let didFocus = false;
const handleFocus = () => {
didFocus = true;
};
- const element = ((node: any): HTMLElement);
try {
- element.addEventListener('focus', handleFocus);
+ // Listen on the document in the capture phase so we detect focus even when
+ // it lands on a different element than the one we called .focus() on. This
+ // happens with