layout bug: Absolutely positioned containers incorrectly constrains child view

Description

React Native's layout engine incorrectly applies width constraints from absolutely positioned parent containers to their child elements, regardless of whether the parent has explicit width constraints or dynamic sizing. When a container uses absolute positioning (position: 'absolute'), it inappropriately constrains the layout dimensions of all descendant elements, even when those children should be free to size themselves naturally. This behavior occurs whether the absolutely positioned parent has a fixed width (e.g., width: 150) or relies on content-based sizing, violating expected CSS layout principles where absolutely positioned elements with dynamic width should not impose constraints on their children. Components in normal document flow correctly allow their children to size naturally, but any absolutely positioned ancestor in the component hierarchy will impose artificial layout constraints throughout the descendant tree.

There may be an argument that if the parent has a fixed size, the constraint is valid, but if the parent is dynamically sized (to fit content), it certainly seems incorrect to me

Steps to reproduce

1. Create a container with absolute positioning - Set position: 'absolute' on a View component, either with fixed width or
   dynamic width
2. Add a child element that needs natural sizing - Place any child component inside the absolutely positioned container that should size itself based on its content. Using a short Text block is the easiest way
3. Compare with normal flow container - Create an identical child component inside a container using normal document flow (no absolute positioning)
4. Observe the constraint difference - The child in the absolutely positioned container will be artificially constrained, while the child in normal flow will size naturally

Minimal Example Structure:

// This child will be constrained
<View style={{ position: 'absolute' }}>

// This child will size naturally

Expected vs Actual Behavior:

• Expected: Children should size naturally regardless of parent positioning method
• Actual: Absolutely positioned parents impose width constraints on all descendants

React Native Version

0.79.2

Affected Platforms

Runtime - iOS

Output of npx @react-native-community/cli info

info Fetching system and libraries information...
System:
  OS: macOS 15.5
  CPU: (10) arm64 Apple M1 Max
  Memory: 3.99 GB / 64.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.16.0
    path: ~/.nvm/versions/node/v22.16.0/bin/node
  Yarn:
    version: 3.6.1
    path: ~/.nvm/versions/node/v22.16.0/bin/yarn
  npm:
    version: 10.9.2
    path: ~/.nvm/versions/node/v22.16.0/bin/npm
  Watchman:
    version: 2024.12.02.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2025.1 AI-251.25410.109.2511.13665796
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 23.0.1
    path: /Users/dcorbin/.jenv/shims/javac
  Ruby:
    version: 3.4.1
    path: /Users/dcorbin/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 19.0.0
    wanted: 19.0.0
  react-native:
    installed: 0.79.2
    wanted: 0.79.2
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

info React Native v0.80.1 is now available (your project is running on v0.79.2).
info Changelog: https://github.com/facebook/react-native/releases/tag/v0.80.1
info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.79.2&to=0.80.1
info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos".

Stacktrace or Logs

From my demo app, logging measurments for two dynamic text widths with 3 different parent setups.

 LOG  Measured abs-fixed  "100": 84px width
 LOG  Measured abs-fixed  "1000": 114.6669921875px width
 LOG  Measured abs-dyn  "100": 53.6669921875px width
 LOG  Measured abs-dyn  "1000": 53.6669921875px width
 LOG  Measured static  "100": 84px width
 LOG  Measured static  "1000": 114.6669921875px width

Of note, the "abs-dyn" lines shows how the widths for "100" and "1000" are equal because of the erroneous constraint.  In the GUI, the view gets colored red when the error is occurring.

MANDATORY Reproducer

https://github.com/dcorbin-bugs/overly-constrained-view

Screenshots and Videos

Start by running the mandatory reproducer at github.com/dcorbin-bugs/overly-constrained-view and compare the absolute-positioned and normal-flow measurements described in the issue. Done means dynamically sized absolutely positioned containers no longer impose the reported width constraint on descendant views, while the fixed-width comparison remains understood and covered by verification.