widgets: Guard _compareScreenOrder against unlaid-out selectables - #184900

Relates to #151536

Description

When _RenderTheater skips layout for an obscured OverlayEntry (e.g., a non-current route behind an opaque route), selectables in that entry remain registered with their SelectionContainerDelegate. When _flushAdditions runs the merge-sort via _compareScreenOrder, it accesses paintBounds / getTransformTo / boundingBoxes.first on RenderBoxes that have no size, throwing StateError in release mode and AssertionError in debug.

This change makes geometry-acquisition failure explicit instead of crashing the sort: each _compareScreenOrder now reads geometry through a small Rect? helper whose on StateError / on AssertionError catch is scoped to just that read. The comparator handles null explicitly — unavailable selectables tie with each other and always sort after available ones — so comparisons involving unavailable selectables are mutually consistent and laid-out selectables keep their correct relative order. (An earlier revision of this PR returned 0 whenever either side lacked geometry; that tied an unlaid-out selectable with every laid-out one — an inconsistent order that List.sort and the merge logic aren't guaranteed to handle.)

Two methods are guarded because _flushAdditions can end up calling either override:

• MultiSelectableSelectionContainerDelegate._compareScreenOrder in packages/flutter/lib/src/widgets/selectable_region.dart — used by top-level SelectionArea / SelectableRegion.
• _SelectableTextContainerDelegate._compareScreenOrder in packages/flutter/lib/src/widgets/text.dart — used when a single Text / Text.rich has multiple _SelectableFragments (e.g., text with WidgetSpans).

Why catch AssertionError too

RenderBox.size evaluates _size ?? (throw StateError(...)). In release mode the StateError fires. In debug mode assert(hasSize) fires first and throws AssertionError before control ever reaches the throw. Catching only StateError would leave debug builds crashing while release silently recovers — the exact opposite of what we want. The on AssertionError clause keeps the guard symmetric across build modes.

Note: avoid_catching_errors is currently commented out in analysis_options.yaml (blocked on dart-lang/linter#4998), so the catch is lint-clean.

Testing

Red/green coverage of both catch branches, in both files

Four testWidgets cases directly exercise the on StateError and on AssertionError catch branches of both guarded methods by registering mock Selectables whose boundingBoxes getter throws. All four are proper red/green tests: they fail on master (the thrown error propagates out of _flushAdditions' post-frame callback and tester.takeException() reports it) and pass with this change (the helper returns null, unavailable selectables sort after available ones, and the sort completes).

• packages/flutter/test/widgets/selectable_region_test.dart — mock Selectables under a top-level SelectableRegion route through MultiSelectableSelectionContainerDelegate._compareScreenOrder (the override in selectable_region.dart). One case per error type.
• packages/flutter/test/widgets/text_test.dart — mock Selectables wrapped in WidgetSpan children of a Text.rich inside a SelectableRegion. The enclosing _SelectableTextContainer's delegate picks up the mocks through SelectionContainer.maybeOf(context), so the post-frame sort routes them through _SelectableTextContainerDelegate._compareScreenOrder (the override in text.dart) specifically. One case per error type.

A comparator-consistency test in each file additionally mixes laid-out and unlaid-out selectables (with the unlaid-out one placed between the others in the tree) and asserts the merged order is deterministic with the unlaid-out entry last.

Widget-level regression guards

Two additional testWidgets cases cover the happy path of both guarded methods so later edits don't accidentally break normal sort behavior:

• selectable_region_test.dart — multiple sibling Text widgets under a SelectionArea inside a Navigator(pages:) where the second page covers the first.
• text_test.dart — Text.rich with WidgetSpan children. paragraph.dart's _getSelectableFragments only splits on placeholder characters, so plain Text produces a single fragment and wouldn't drive the sort — WidgetSpan placeholders are required to get multiple fragments per container. Kept at the widgets/ layer (TestWidgetsApp + TestPage) to match the rest of text_test.dart.

Full affected suites are green locally:

flutter analyze --flutter-repo is clean on the full tree.

Additional evidence: dart2wasm runtime repro

The red/green unit tests prove the catch branches work in isolation. The dart2wasm runtime repro proves the guard prevents the actual production crash end-to-end:

Repro: https://github.com/davidmigloz/flutter_selection_crash — three approaches (A / B / C) that crash reliably on dart2wasm Chrome (flutter run -d chrome --wasm) with StateError: Bad state: RenderBox was not laid out thrown from _compareScreenOrder. Each approach hits a different frame in the same method. Approaches A and C land in selectable_region.dart; approach B lands in text.dart via _SelectableFragment.boundingBoxes.

Verified locally: Built the repro app against this branch and exercised all three approaches with flutter run -d chrome --wasm (dart2wasm debug). All three previously crashed, none throw the error anymore. The crash also reproduces on master in DDC debug, dart2js release, and dart2wasm release — same _compareScreenOrder code path in each case — so the guard is expected to cover them too, but only dart2wasm debug was verified by hand on this branch.

Why not a route-level SelectionContainer.disabled wrapper?

We originally explored wrapping non-current route content in SelectionContainer.disabled inside _ModalScopeState.build(). This approach is fundamentally limited: SelectionArea / SelectableRegion create their own SelectionContainer(registrar: this, ...) inside the route (selectable_region.dart:1944), which installs a fresh registrar that shadows the disabled outer scope. The route-level wrapper cannot suppress selection inside nested SelectionArea instances — exactly the case this issue is about. Independent review of four separate research passes converged on the comparator-level guard as the only viable surgical framework fix.

Known limitations

• Dead zones (#182573): Stale selectables from offstage routes remain registered and can intercept drag events (silent variant). This PR is a crash guard at sort time — it prevents _flushAdditions from crashing when it encounters an unlaid-out selectable, but it does not remove those selectables from the delegate or fix the dead-zone behavior itself. App-level workarounds like flutter/packages#11062 (for go_router) remain needed for the behavioral fix. A proper framework fix is likely structural rather than comparator-based: the underlying problem is that selectables from obscured routes can remain registered even when _RenderTheater skips laying them out, so they continue participating in selection before their geometry is valid. Fixing that cleanly would likely require a route/overlay-driven visibility or readiness signal in the selection system itself, so hidden selectables are suppressed or unregistered until they are laid out again.
• Other unguarded geometry reads: selectable_region.dart and text.dart have other boundingBoxes / getTransformTo(null) sites outside _compareScreenOrder (e.g., _handleSelectWordSelectionEvent around line 2969 in selectable_region.dart; text.dart at lines 1069, 1071, 1407). These are less frequently hit in the _flushAdditions post-frame path — the vast majority of production Sentry events for this issue land in _compareScreenOrder. Follow-up PRs can guard them if reported.

Related

• Upstream comment with repro + analysis + fix direction
• flutter/packages#11062 — go_router-level workaround, reviewed by @Renzo-Olivares
• flutter/flutter#157996, flutter/flutter#158918 — prior attempts (incomplete)
• flutter/flutter#182573 — sibling dead-zone variant (not fixed here)

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.