Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

waitUntilVisible() fails on Columns with SizedBox #2463

Closed
FritzMatthaeus opened this issue Dec 21, 2024 · 3 comments
Closed

waitUntilVisible() fails on Columns with SizedBox #2463

FritzMatthaeus opened this issue Dec 21, 2024 · 3 comments

Comments

@FritzMatthaeus
Copy link
Contributor

I have found an answer on why the waitUntilVisible() test fails when using a Key or searching by Class. It has to do with the Widget containing a Column with a SizedBox.

this will be found when calling $(Keys.elementA).waitUnitilVisible() :

class ElementA extends StatelessWidget {
  ElementA() : super(key: Keys.elementA);

  @override
  Widget build(BuildContext context) {
    return const Column(
      children: [
        Text(
          'Element A',
        ),
      ],
    );
  }
}

this will NOT be found when calling $(Keys.elementB).waitUnitilVisible() or $(ElementB).waitUntilVisible():

class ElementB extends StatelessWidget {
  ElementB() : super(key: Keys.elementB);

  @override
  Widget build(BuildContext context) {
    return const Column(
      children: [
        Text(
          'Element B',
        ),
        SizedBox(height: 48)
      ],
    );
  }
}

I have created a reproducable example: Patrol Bug Finder Example

Originally posted by @FritzMatthaeus in #2459 (comment)

@FritzMatthaeus
Copy link
Contributor Author

While the pull request will fix the problem on the given example, the overall problem seems to be bigger: The hitTestable will fail, even with Alignments, if we hit some "empty" space. In the example, the test will pass because we can get a result on finder.hitTestable(at: Alignment.topCenter). But it will fail, if we wrap the Column into a Padding.

The Pull Request might be an enhancement, up to your decision. But i would recommend to update the Documentation and clarify, that a finder with byKey or byClass should not be used on Complex Widgets with Paddings, Columns inside itself or it's children. At least if you want to check the visibility. It should be set on lowest child inside the widget tree.

Setting the Key as in this example (though this is what i want to check, if ElementB is visible), will fail. With or without alignments:

class ElementB extends StatelessWidget {
  ElementB() : super(key: Keys.elementB);

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(24.0),
      child: const Column(
        children: [
          Text(
            'Element B',
          ),
          SizedBox(height: 48), 
          Text('Some other widget'),
        ],
      ),
    );
  }
}

Instead you should set the key on a lower element to make sure that hitTestable() works:

class ElementB extends StatelessWidget {
  ElementB({super.key})

  @override
  Widget build(BuildContext context) {
    return Padding(
      padding: const EdgeInsets.all(24.0),
      child: const Column(
        key: Keys.elementB // <- here with the PR merged
        children: [
          Text(
            'Element B',
           key: Keys.elementB // <- or here without the PR
          ),
          SizedBox(height: 48), 
          Text('Some other widget'),
        ],
      ),
    );
  }
}

As most "Newbies" like me would probably say "Yeah, let's go for visible and not for exist when we check the Widgets", it would perhaps help to clarify that visible == false does not exactly mean that the widget is not visible in the common sense, but that hitTestable() does not "find" it. So either test a nested Widget or be happy with just testing exist == true.

All in all, thank you very much for this library and maybe i am just addressing some old stuff for experts that has already been widely discussed. But i ran into it and it really made me, not understanding "why" it was not visible though i could see it on the screen. :)

@pdenert
Copy link
Collaborator

pdenert commented Jan 17, 2025

Closing as it was fixed in #2464

@pdenert pdenert closed this as completed Jan 17, 2025
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar problem, please file a new issue. Make sure to follow the template and provide all the information necessary to reproduce the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 24, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants