Open tvolkert opened 4 years ago
cc @jacob314
Looks like we are doing a bad job at determining which widget is visually on top of which widget in the render tree for that case. To get it right 100% of the time we'd need to use some mechanism for the inspector hit testing that more exactly matches what is rendered on the device. Ideally hit testing would be based on determining which render object(s) actually painted the specific pixel. As a workaround if you hit issues like that, you can take advantage of the fact that the inspector will select a render object if you select right at the edge of the render object even if the inspector doesn't think the render object is visually in front of the other widget. If you hold down the mouse while using an emulator it is fairly easy to see the bounding box for each render object and move the mouse until you are right on top of the desired widget.
The framework already has hit testing APIs that it uses e.g. when the user taps or clicks. How much information do the debugging tools get from their hit testing routines that the framework's hit testing wouldn't provide? I wonder if a good long-term solution would be to just beef up the framework APIs as needed.
Doing debugger hit testing correctly as part of the regular hit testing mechanism would require significant breaking changes to the hit testing api.
For example, hitTestSelf
and hitTestChildren
would need to take an additional argument to indicate that a hit testing algorithm suitable for debugging tools should be used instead of the regular one. For example, the logic to absorb a hit doesn't make sense when using a debugging tool.
Implementing this fully would require a major breaking change and it would likely require non-trivial changes in many render objects.
An interesting middle ground could be to bias the inspector debugger specific hit testing mechanism to bias towards results that are descendants of the hit test result returned by the regular algorithm. That might be able to cover up cases where the inspector hit testing algorithm is wrong about what widget is in front.
Reproducible on latest master channel.
This is still an issue, Jun 2021. Please fix it, it would bring so much ease to the dev experience.
Still an issue as of Oct 2021.
This would fit nicely in Flutter's developer experience theme of work.
Reproduces on the latest versions of flutter using the code sample and steps provided above.
This issue is assigned but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!
This issue was assigned to @jacob314 but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.
Steps to reproduce
Run the following app:
sample app
```dart import 'dart:ui' show window; import 'package:flutter/material.dart'; void main() { runApp(BugReport()); } class BugReport extends StatelessWidget { @override Widget build(BuildContext context) { return Localizations( locale: Locale('en', 'US'), delegates: [ DefaultWidgetsLocalizations.delegate, DefaultMaterialLocalizations.delegate, ], child: WidgetInspector( selectButtonBuilder: (BuildContext context, VoidCallback onPressed) { return FloatingActionButton( child: const Icon(Icons.search), onPressed: onPressed, mini: true, ); }, child: MediaQuery( data: MediaQueryData.fromWindow(window), child: Navigator( onGenerateRoute: (RouteSettings settings) { return MaterialPageRouteThen:
Expected behavior
You expect the widget inspector to detect and highlight the cyan box (the
Container
or itsSizedBox
parent).Actual behavior
The widget inspector detects and highlights the
Align
widget that houses the "Open Modal Dialog" box. This widget is (a) under a modal barrier and cannot receive input events, and (b) painted over and is obscured by the cyan box in the modal dialog -- and so the widget inspector should not be able to select it.Other info
I have variants of this happen quite often, and it completely removes the utility of the widget inspector when it happens, so marking as P3.
Version info
``` [✓] Flutter (Channel master, 1.21.0-7.0.pre, on Mac OS X 10.15.3 19D76, locale en-US) • Flutter version 1.21.0-7.0.pre at /Users/tvolkert/project/flutter/flutter • Framework revision d261f1ef58 (8 days ago), 2020-08-03 00:59:36 -0400 • Engine revision 083282e33b • Dart version 2.10.0 (build 2.10.0-2.0.dev 365525432a) [✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3) • Android SDK at /Users/tvolkert/Library/Android/sdk • Platform android-28, build-tools 28.0.3 • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593) • All Android licenses accepted. [✓] Xcode - develop for iOS and macOS (Xcode 11.6) • Xcode at /Applications/Xcode_11.6.app/Contents/Developer • Xcode 11.6, Build version 11E708 • CocoaPods version 1.9.2 [✓] Chrome - develop for the web • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome [✓] Android Studio (version 4.0) • Android Studio at /Applications/Android Studio.app/Contents • Flutter plugin version 48.0.2 • Dart plugin version 193.7361 • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593) [✓] Connected device (3 available) • macOS (desktop) • macos • darwin-x64 • Mac OS X 10.15.3 19D76 • Web Server (web) • web-server • web-javascript • Flutter Tools • Chrome (web) • chrome • web-javascript • Google Chrome 84.0.4147.105 ```