@ueman is it possible to find out which screen (maybe the root Scaffold?) a widget belongs to?
For example, MainScaffold.btn_login, I know that the btn_login comes from the MainScaffold screen.
I could not find any way that really makes sense.

If you have the context of the widget, you can do ModalRoute.of(context).settings.name;.

You have to track which StatefulElement is the closest to the widget which gets tracked. Via that StatefulElement, you can do ModalRoute.of(statefulElement.state.context).settings.name.

So in _getDescriptionFrom you can do something like

TappedWidget? _getDescriptionFrom(Element element) {
    String? currentRouteName;
    // Add the following lines
    final widget = element.widget;
    if(element is StatefulElement) {
      currentRouteName = ModalRoute.of(statefulElement.state.context).settings.name;
    }
    // Used by ElevatedButton, TextButton, OutlinedButton.
    if (widget is ButtonStyleButton) {
      if (widget.enabled) {
        return TappedWidget(
          element: element,
          description: _findDescriptionOf(element, true),
          type: 'ButtonStyleButton',
        );
      }
    } else if (widget is MaterialButton) {
      if (widget.enabled) {
        return TappedWidget(
          element: element,
          description: _findDescriptionOf(element, true),
          type: 'MaterialButton',
        );
      }
    } else if (widget is CupertinoButton) {
      if (widget.enabled) {
        return TappedWidget(
          element: element,
          description: _findDescriptionOf(element, true),
          type: 'CupertinoButton',
        );
      }
    } else if (widget is InkWell) {
      if (widget.onTap != null) {
        return TappedWidget(
          element: element,
          description: _findDescriptionOf(element, false),
          type: 'InkWell',
        );
      }
    } else if (widget is IconButton) {
      if (widget.onPressed != null) {
        return TappedWidget(
          element: element,
          description: _findDescriptionOf(element, false),
          type: 'IconButton',
        );
      }
    } else if (widget is GestureDetector) {
      if (widget.onTap != null) {
        return TappedWidget(
          element: element,
          description: '',
          type: 'GestureDetector',
        );
      }
    }

    return null;
  }

No clue about the performance impact of calling ModalRoute.of for each StatefulElement but it could be a bit too much. Better to optimize it :D

Yeah and then it works only for StatefulElement as well, StatelessElement elements don't have a state.
Maybe I will mention in the docs for now that the key must be unique across screens as well.
The other option is if I make it work along with SentryNavigatorObserver, because SentryNavigatorObserver always knows what's the current route if the observer is installed.

True, but I would bet that it's basically guaranteed that there's one, though.

I wouldn't use SentryNavigatorObserver tbh, because it's common to have multiple navigators and then you have to figure out which one is the navigator to get the current route from

h: Consider this:

Card(
                child: GestureDetector(
                  onTap: () => {
                    //open Card
                  },
                  child: Stack(
                    children: [
                      //fancy card layout
                      ElevatedButton(
                        onPressed: () => {
                          //mark card as favorite
                        },
                        child: const Text('Favorite'),
                      ),
                    ],
                  ),
                ),
              )

If a user press the "Favorite" ElevatedButton, the element found will always be the GestureDetector.
I guess this will be a problem to really detect a potential problem.

It's kind ok to keep this as it is. Since UI Transactions are meant to a bag for spans. Maybe we're ok to not have the perfect origin of a transaction as long we have a transaction.

But if you can figure it out how to solve this would be nice.

Very good catch, the elementFinder always goes to the GestureDetector.
@ueman any ideas what to do here? since we don't know the instance of the onTap or onPressed to compare, I don't know if we can solve it.
@brustolin The question is, does this even make sense? Having a parent onTap and an onPressed child? Is this a real use case? Flutter always executes the onPressed from the ElevatedButton, always ignores the onTap from GestureDetector, maybe we should just go till the very end of the tree and use the last found child?

Yes, this is a real use case.
I had used this a lot.

@ueman any ideas what to do here? since we don't know the instance of the onTap or onPressed to compare, I don't know if we can solve it.

maybe we should just go till the very end of the tree and use the last found child?

Yeah, maybe don't stop searching on the first hit, but for the smallest hit?

Maybe there's a way to get some information from the gesture arena (which is the mechanism which decides which widget was tapped)? There's some information here https://docs.flutter.dev/development/ui/advanced/gestures#gesture-disambiguation

It turns out that going to the latest level of child is also wrong, because it ends up with an InkWell which is a child of the desired ElevatedButton.
Will do a bit of research.

For now, I dropped support for the nested GestureDetector so the PR is unblocked, I will keep searching on how to apply the gesture disambiguation
https://docs.flutter.dev/development/ui/advanced/gestures#gesture-disambiguation