skip to content

In Flutter DevTools, how do you use the Widget Inspector's Select Widget Mode to find which widget draws a given element on screen?

level: juniorimportance: must knowfreq 55%

answer

  1. toolbar toggle, then tap the device
  2. tree scrolls to the matching node
  3. project widgets only by default
  4. Show implementation widgets toggle
  5. Widget Explorer: properties, flex, render object

basics

~20 s

Turn on Select Widget Mode in the DevTools Flutter inspector and tap the element in the running debug app; the inspector selects that widget, scrolls the widget tree to it, and shows its size, constraints and properties in the Widget Explorer.

solid answer

~40 s

I open the **Flutter inspector** in DevTools, click **Select Widget Mode**, and tap the element on the device. The framework hit-tests the tap, the inspector selects that widget and scrolls the **widget tree** to its node, and the **Widget Explorer** shows its properties, `size` and `constraints` (plus a flex explorer for `Row`, `Column` or `Flex`). By default the tree lists only widgets created in my project; **Show implementation widgets** reveals the ones framework `build` methods insert. It only works in debug mode, because the inspector's service extensions are registered only there, and the tree mirrors my source thanks to `--track-widget-creation`, which `flutter run` enables by default.

code

bash · 4 lines
bash
# Start a debug session; widget-creation tracking is on by default
flutter run
# In the flutter run terminal, press i to toggle the on-device widget inspector,
# or open the printed DevTools URL and use Select Widget Mode there.

go deeper

for a junior

Recall the loop: open the Flutter inspector, turn on Select Widget Mode, tap the element, read the selected node. Know it needs a debug run.

for a middle

Explain why the tree matches your source (track-widget-creation), what Show implementation widgets adds, and which Widget Explorer tab to read for size, constraints and flex layout.

for a senior

Show that you use the inspector to walk up to the constraining parent rather than guessing, and that you know its limits: debug only, edits are temporary, const identity differs in debug.

for a principal

Frame the inspector as part of the team's debugging workflow: shared package directories for a monorepo widget library, and a habit of fixing layout at the owning widget or theme.

## What the Widget Inspector is The **Flutter inspector** is the DevTools screen (also embedded in VS Code, Android Studio and IntelliJ) that shows a running app's **widget tree** and connects what you see on the device to the widget that produced it. It talks to the app through **service extensions** that the framework registers on the Dart VM service, so the app must run in **debug mode** with a debugger connection, for example after `flutter run` or an IDE debug launch. It answers two everyday questions: - *Which widget draws this pixel?* This is the job of **Select Widget Mode**. - *Why is it this size and in this place?* This is the job of the **Widget Explorer** panel, which shows `size`, `constraints`, properties and, for flex layouts, the flex explorer. ## Select Widget Mode, step by step 1. Open DevTools and switch to the **Flutter inspector** tab. 2. Click **Select Widget Mode** in the inspector toolbar. The app enters widget-select mode and shows an on-device button to exit it. 3. Tap the element on the device or emulator. The framework hit-tests the tap, highlights the chosen widget, and DevTools **scrolls the widget tree to the matching node** and selects it. 4. Read the node in the Widget Explorer, walk up to its parents in the tree, or jump to the source line that created it. 5. Toggle the button again to leave the mode. While the mode is on, an on-device control switches between tap-to-select and letting taps reach the app, so you can navigate to another screen without leaving the mode. The link also runs the other way: selecting a node in the tree updates the highlighted widget on the device. ## Reading the widget tree - By default the tree lists only widgets **created in your project's root directory** (your `Scaffold`, `Padding`, `Row` and custom widgets), which keeps it close to your source. - **Show implementation widgets** reveals the widgets that the framework's own `build` methods insert, such as the `RichText` under every `Text`, drawn in a lighter font and collapsed into groups. - **Package directories** in the inspector settings add other local packages, such as a monorepo's shared widget library, to the default view. - The tree mirrors your source because of **`--track-widget-creation`**, a `flutter` tool flag that defaults to on and records where each widget was constructed. It only has an effect in JIT (debug) builds. - With **auto-refresh** on, which is the default, the tree reloads after a hot reload or a navigation event. ## The Widget Explorer | Tab | What it shows | When it appears | |---|---|---| | Widget properties | a mini layout view (width, height, padding) and the widget's properties, marking values that equal the parameter's default | any selected widget | | Flex explorer | main and cross axis, alignment, flex factor, fit, constraints, overflow | a `Row`, `Column`, `Flex` or a direct child of one | | Render object | every property set on the widget's render object | a widget that has a render object | The current inspector replaced a legacy one whose panels were called the *details tree* and the *layout explorer*. DevTools 2.58 deleted the option to switch back, so older tutorials name panels the tool no longer shows. ## Limits worth knowing - **Release builds are out of reach.** The inspector's service extensions are registered inside debug-only asserts, and widget-creation tracking only works for JIT debug compiles. - **Inspecting changes nothing in your code.** Values you edit in the flex explorer apply to the running app only and are reverted on hot reload. - **Const identity differs in debug.** Because tracking records a creation location per call site, otherwise identical `const` widgets are not considered equal in debug builds; that is expected. ## How to present it in an interview Describe the loop rather than the buttons: select the widget on the device, confirm it in the tree, read `size` and `constraints` in the Widget Explorer, then open the code that created it. Constraints flow down the tree and sizes flow back up, so when a widget has the wrong size the useful next step is usually to walk **up** the tree to the parent that constrained it.

  • Why can't you open the Widget Inspector against a release build of a Flutter app?
    The framework registers the inspector's service extensions inside debug-only asserts, and `--track-widget-creation` only works for JIT debug compiles. A release build is AOT-compiled with asserts stripped, so there is nothing for DevTools to query. For layout debugging you run the app in debug mode.
  • What does Flutter's --track-widget-creation flag do, and what side effect does it have?
    It defaults to on and instruments widget construction with source locations, so the inspector can show a tree shaped like your code and jump to the line that built a widget. The side effect is that otherwise identical `const` widgets are not treated as equal in debug builds. You can disable it with `--no-track-widget-creation`, at the cost of a deeper, harder tree.

saying these in an interview costs you the question

  • The Widget Inspector can be attached to a release build installed from the store.
  • The default widget tree lists every widget, including those the framework inserts.
  • You must wrap your app in a WidgetInspector widget yourself to use the inspector.
  • Values changed in the inspector are written back into the source file.
  • The inspector only shows render objects, not the widgets you wrote.