Actions are applied to overlapping views

[silyevsk]

If there's a scrollView A overlapped with a scrollview B at the bottom, then a scroll-down action applied to the A element generates touches at the bottom of it and thus B is scrolled instead.

If there's a button A overlapped with a button B at the center, then a tap action on A causes an exception.

An example project for these cases with the tests: https://github.com/wix/earlgrey-with-overlapping-interactable-views

I think that there should be a check of the area available for tap and scroll (the first touch point). Something like this (for tap): going over all the views that appear above the view and subtracting areas covered by other views that would catch the touches/gestures instead of the view. Then the action point should be a point in the area. If there's too small area left, then it may be good to throw an exception (it would be nice if the minimum amount/percent of space is configurable) - because it's not enough area for a real user to tap.

Another (simpler to implement) option is to have a list of possible locations for touch points and checking only those points (checking if the view that is going to accept scroll at the bottom center of the view is indeed the view itself and if not, try switching to alternative locations).

[tirodkar]

@silyevsk Are you scrolling to find a particular element in the scroll view? Using the usingSearchAction method, you should be able to limit the scroll amount, thus preventing the touches from being added.

[silyevsk]

It's not that I have a specific test that fails (we had an issue with react native warning view covering a scroll view, but we have a workaround for that). In the described cases however, an action applied to a matched element (in code) is in fact applied to a wrong element (just because it covers some of the element). It's not a matter of limiting scrollView, it's that a wrong scrollView is scrolled instead of the one that was matched.

[khandpur]

I've confirmed a bug in EarlGrey that's causing this behavior. In GREYVisibilityChecker, when the visible rect (xmin, ymin, xmax, ymax) is calculated from overlapping regions ymax and xmax aren't reset if a region is overlapped by another. We end up returning the whole rect as visible and the scroll logic picks the max area for the requested scroll amount which happens to fall in the overlapped regions.

[khandpur]

@silyevsk I am unable to make the app crash with the 2nd test case testTapOnBackrgoundButton. I don't see any exceptions. What xcode and ios version did you run that test on?

[silyevsk]

@khandpur It turns out I was checking against EarlGrey 1.8.0 (no idea how, I installed it via CocoaPods without specifying a version..) I've checked it now with 1.9.4 and it works fine. I'm sorry I didn't check the version before opening the issue. Thank you for your time.

[khandpur]

The overlapping scroll view issue is still legit and we have a fix for it. Using this issue to track it.