Error: Flutter Inspector navigates to framework source instead of user code in Flutter 3.22.3

[xuvien]

Description

In Flutter 3.32.3, the Flutter Inspector no longer navigates to the widget usage in my codebase when selecting a widget from the widget tree. Instead, it opens the widget definition from the Flutter SDK itself.

For example, when I select a CupertinoButton in the Flutter Inspector, instead of opening the line where I used CupertinoButton in my own Dart file (e.g. home_screen.dart), it jumps directly to the Flutter SDK source (cupertino.dart).

This behavior breaks the expected functionality where the Inspector should navigate to the actual widget usage in user code (i.e. call site), not its definition.

---

Steps to Reproduce:

1. Create a Flutter app.

2. Use a standard widget like CupertinoButton or ElevatedButton in your widget tree:

CupertinoButton(
  child: Text('Click'),
  onPressed: () {},
)

3. Run in debug mode with Flutter 3.32.3

4. Open Flutter Inspector and select the button widget in the widget tree.

5. Inspector opens the Flutter SDK source instead of your own Dart file.

---

Expected Behavior:

Flutter Inspector should open the file and line where the widget is used in my application code, not inside the Flutter SDK.

---

Actual Behavior:

Inspector opens cupertino.dart, material.dart, or another SDK file where the widget is defined, ignoring the actual location of usage in my project.

[jakemac53]

This could be a flutter issue, if the widget locations are being reported differently now?

[jakemac53]

Possible related issue https://github.com/flutter/devtools/issues/8802?

[jakemac53]

We should escalate this to a P1 potentially if we are able to reproduce it or get more reports/+1s

[kenzieschmoll]

This issue also looks related to https://github.com/flutter/devtools/issues/9063, which may provide some breadcrumbs for debugging / finding a fix.

[xuvien]

Would love to see this fixed — Inspector should go to the widget usage in user code by default.

That said, the current behavior could be useful for debugging 3rd-party packages or checking if a bug comes from the SDK. Maybe this "bug" could become a feature: add a checkbox like:

"Prefer navigating to widget definition"

Fix first, then make it toggleable — best of both worlds. ❣️

[elliette]

This was one of the top complaints from the DevTools user survey - selecting a widget can cause the implementation widget from the framework to be opened in the user's IDE.

I figured out how to repro this - this happens if a user has implementation widgets hidden in their widget tree, but selects an implementation widget on their app.

In DevTools, we walk up the tree from the selected implementation widget to the closest parent widget in their local project. This was implemented in https://github.com/flutter/devtools/pull/8625

However, in Flutter's on-device widget inspector, we show the widget they actually selected on their device, and send the navigate event to the IDE for that same widget. This was implemented in https://github.com/flutter/flutter/pull/165924

There are a few options here:

• The Flutter Widget Inspector is aware of whether implementation widgets are shown or not, and only selects implementation widgets when implementation widgets are visible in the tree
• DevTools, and not the Widget Inspector, is responsible for sending the navigate event to the IDEs. This is my preferred approach, because it would also allow us to tackle making "jump-to-code" and toggleable setting in DevTools, which has been requested by users for a while (tracking issue https://github.com/flutter/devtools/issues/5063)

Bumping priority to P1.

[xuvien]

Is there a temporary fix to prevent it from opening the original dev files? Because every time the Widget Inspector runs, it opens a lot of original files, which is a bit annoying. Or maybe there’s a patch for this issue. The Flutter Widget Inspector is a great feature, it’s just that single problem

[elliette]

I thought of a simpler solution than what I outlined in https://github.com/flutter/devtools/issues/9252#issuecomment-3366266089.

I still think the moving sending ToolEvent-navigate out of the framework and into DevTools is a good idea, and can be tackled as follow-up. However, in the interest in getting a fix in for the next stable release (cut-off in two days) I think the following solution which only requires changes to the framework is sufficient:

Whenever a user selects a widget that was not created in their project files:

• if they selected it using the on-device inspector, we open the file for the nearest ancestor widget in their project files. (e.g., a user selects RichText in the framework, we open the Text widget in their project)
• if they selected it in the DevTools widget tree, we open the file for that widget. (e.g., a user explicitly selects the RichText in the framework, we also open the RichText widget in the Framework)

This solution fixes the current issue, without regressing the fix for https://github.com/flutter/devtools/issues/9063.

[xuvien]

Oh, I just saw the update you posted, and I think it's pretty interesting. I'm really looking forward to this feature being updated in the stable release

[xuvien]

I thought of a simpler solution than what I outlined in #9252 (comment).

I still think the moving sending ToolEvent-navigate out of the framework and into DevTools is a good idea, and can be tackled as follow-up. However, in the interest in getting a fix in for the next stable release (cut-off in two days) I think the following solution which only requires changes to the framework is sufficient:

Whenever a user selects a widget that was not created in their project files:

• if they selected it using the on-device inspector, we open the file for the nearest ancestor widget in their project files. (e.g., a user selects RichText in the framework, we open the Text widget in their project)
• if they selected it in the DevTools widget tree, we open the file for that widget. (e.g., a user explicitly selects the RichText in the framework, we also open the RichText widget in the Framework)

This solution fixes the current issue, without regressing the fix for #9063.

Hi, i checked until now but it seems this problem is not solved yet, in the latest version it is still like that

[elliette]

Hi @xuvien - this is now fixed on Flutter 3.38. Please upgrade and if you are stilling running into this file a new issue. Thank you!