Repository navigation
Feature Request: Search widget tree by error chain path #10012
Description
Activity
When an overflow error occurs, the error output already includes a link to open this widget in the Flutter Inspector. The supported IDEs (IntelliJ / Android Studio and VS Code) also show an IDE notification with the same link to open the widget in the inspector. Here is an example:
══╡ EXCEPTION CAUGHT BY RENDERING LIBRARY╞═════════════════════════════════════════════════════════ The following assertion was thrown during layout: A RenderFlex overflowed by 336 pixels on the right. The relevant error-causing widget was: Row Row:file:///Users/kenzieschmoll/develop/demos/devexp_demos/devtools_companion/lib/src/screen s/inspector/inspector_screen.dart:470:21 To inspect this widget in Flutter DevTools, visit: http://127.0.0.1:54198/q-OKgkDPQVI=/devtools//#/inspector?uri=http%3A%2F%2F127.0.0.1%3A54198%2 Fq-OKgkDPQVI%3D%2F&inspectorRef=inspector-0 The overflowing RenderFlex has an orientation of Axis.horizontal. The edge of the RenderFlex that is overflowing has been marked in the rendering with a yellow and black striped pattern. This is usually caused by the contents being too big for the RenderFlex. Consider applying a flex factor (e.g. using an Expanded widget) to force the children of the RenderFlex to fit within the available space instead of being sized to their natural size. This is considered an error condition because it indicates that there is content that cannot be seen. If the content is legitimately bigger than the available space, consider clipping it with a ClipRect widget before putting it in the flex, or using a scrollable container rather than a Flex, like a ListView. The specific RenderFlex in question is: RenderFlex#71886 relayoutBoundary=up13 OVERFLOWING: creator: Row ← Column ← Padding ← Flexible ← Column ← Flexible ← Row ← Padding ← ClipPath ← DecoratedBox ← Container ← ShadCard ← ⋯ parentData: offset=Offset(0.0, 184.0); flex=null; fit=null (can use size) constraints: BoxConstraints(0.0<=w<=320.0, 0.0<=h<=Infinity) size: Size(320.0, 20.0) direction: horizontal mainAxisAlignment: start mainAxisSize: max crossAxisAlignment: start textDirection: ltr verticalDirection: down spacing: 0.0 ◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤◢◤ ◢◤◢◤◢◤ ══════════════════════════════════════════════════════════════════════════════════════════════ ══════For this reason, I'm going to close out this issue as not planned, because we do already provide support for the direct error-to-inspector workflow you are describing in this issue. Thanks!
When a layout error occurs (e.g., RenderFlex overflowed), Flutter prints a widget ancestor chain like:
SizedBox ← Flexible ← Stack ← Row ← Padding ← DecoratedBox ← ConstrainedBox ← Container
Currently, there is no way to paste this chain into DevTools to locate the exact widget node in the Inspector tree. The existing search only matches a single widget name, which returns dozens of results for common widgets like SizedBox or Padding.
Proposed Solution
Add a "Search by widget chain" mode in the Inspector's search bar that:
Accepts a widget ancestor chain (using ← or ◂ as separators, matching Flutter's error output format)
Walks the widget tree and finds nodes whose ancestor path matches the given chain
Highlights and scrolls to the matching node(s)
Example
Given this error output:
SizedBox ← Flexible ← Stack ← Row
The search would find SizedBox nodes that have Flexible as parent, then Stack, then Row — and jump to the matching location in the tree.
Why This Is Useful
Direct error-to-inspector workflow: Copy the chain from the error console → paste into DevTools → land on the exact widget. No manual tree navigation needed.
Eliminates ambiguity: Searching for SizedBox alone may return 50+ results. The chain narrows it to the exact instance.
Partial matching: The chain from the error is often a subset of the full tree. The algorithm should support subsequence matching (the chain nodes appear in order but not necessarily adjacent in the full tree).
Additional Context
The widget chain format is already standardized in Flutter's error output, so no new format needs to be invented.
This could be a separate search mode (e.g., toggled by a button next to the search bar, or auto-detected when ← is present in the query).
The chain in errors sometimes includes RenderObject names — the search could optionally strip or ignore those.
Contribution
I'm interested in implementing this feature. Happy to be assigned and submit a PR if the team approves the approach.