[huntie]

Summary

The LogBox inspector applies the safe area to its header and footer buttons only, so the error message, code frames and stacks run under a side inset, such as the iPhone Duo's status column or the notch in landscape. This affects the "Failed to compile" screen, which cannot be dismissed, and the dismissable inspector alike.

Changes

• Read the inspector root's insets with experimental_onSafeAreaInsetsChange, and apply the left and right insets as padding to the message header and to the content inside the body's ScrollView, so backgrounds stay edge to edge.
• Map the physical insets to paddingStart and paddingEnd by isRTL, so the RTL left/right swap doesn't move them.

This adds no SafeAreaView use, ahead of its removal.

Changelog:
[General][Fixed] - LogBox: Keep the inspector's message, code frames and stacks clear of horizontal safe area insets

Test Plan

yarn test packages/react-native/Libraries/LogBox

✅ Passes, with no snapshot changes.

RNTester on the iPhone Duo simulator (iOS 27.1 runtime, Xcode 27.2), folded display, where the status column is a right inset. The syntax error is an unresolvable import added while the app runs, delivered by Fast Refresh; the render error is a throw in RNTesterApp.

Syntax error, before	Syntax error, after

✅ The message and code frame wrap before the status column; the header and message backgrounds still reach the edge.

Render error, before	Render error, after

✅ The dismissable inspector gets the same inset; the header and Dismiss, Minimize and Copy buttons are unchanged.

Render error, "See More" expanded	Expanded and scrolled

✅ With the message inside the ScrollView, it and the component stack keep the inset while scrolling.

iPhone 18 Pro (iOS 27.0 runtime), portrait, syntax error, after

✅ With no side insets, the layout is unchanged.

ℹ️ Not run locally: the Fantom LogBox snapshot tests (yarn fantom), left to CI.

[huntie]

@huntie-bot Once this lands, pick request it to both 88 and 89.

[javache]

Can't we use paddingLeft and paddingRight here to avoid the manual RTL logic?

[huntie]

Tested this on the iPhone Duo simulator in RTL, I think the manual RTL logic is needed regardless (for as long as doLeftAndRightSwapInRTL exists).

RTL	Current (paddingStart/End + isRTL)	paddingLeft/paddingRight
doLeftAndRightSwapInRTL: true (default)
doLeftAndRightSwapInRTL: false

This mapping also holds with doLeftAndRightSwapInRTL: false, since paddingStart/End resolve by layout direction alone (verified on device), so I'll keep it as is.

I guess Left/Right might be a semantic improvement, but I don't think it reduces the logic, unless you had something else in mind?

[robhogan]

@huntie-bot Once this lands, pick request it to both 88 and 89.

0.88 doesn't have experimental_onSafeAreaInsetsChange (it was added in #58109 and never picked)

[huntie]

@robhogan Gah, yeah you're right.

@huntie-bot Amend: Pick this to only 0.89 please.