assertVisible is returning true even if the element is not visible inside a scroll view. UiElement bounds are not correctly captured in ViewHierarchy for iOS

[prasanta-biswas]

Describe the bug
assertVisible is returning true for elements inside a scroll view even if the element is not inside the view port. Similar behaviour is notices with assertNotVisible returning false when element is visible and same happening while using visible/notVisible in rulFLow or repeat commands.

To Reproduce

1. The app should have a scroll view
2. Scroll view should have elements with text
3. Run a flow having and assertVisible for an element in the scroll view which is not inside the view port.

Expected behavior
The command assertVisible should return false for elements that are not inside view port even if they are in a scroll view.

Environment information (please complete the following information):

• Maestro version: 1.36.30
• Platform: iOS 15
• Framework: Native iOS
• Device model and OS version: iPhone6 Simulator
• Host: Mac M1

[prasanta-biswas]

I think this is a known issue: https://maestro.mobile.dev/troubleshooting/known-issues#ios-issues-with-lists-uicollectionview-uitableview-that-fetch-data-on-scroll

[prasanta-biswas]

The suggestion provided is not working

// This function should be implemented in a class conforming to UITableViewDelegate
// in case of UICollectionView `collectionView(_:willDisplay:forItemAt:)` from
// UICollectionViewDelegate should be used
func tableView(_ tableView: UITableView,
                   willDisplay cell: UITableViewCell,
                   forRowAt indexPath: IndexPath) {
  // additional check whether the cell is currently visible or not is needed
  // to make sure calls caused by XCTest or other random tableView reloads
  // do not unintentional data fetch request
  guard let visibleIndexPaths = tableView.indexPathsForVisibleRows,
            visibleIndexPaths.contains(indexPath),
            <additional checks that were previosly there> else { return }
        
  print("load new data..")
}

[arthurhammer]

Same issue here. Suggested workaround is not working.