Open LeoNatan opened 7 years ago
You may be able to work around this using one of the start point variants like grey_scrollInDirectionWithStartPoint
Has this been fixed? I am not able to reproduce in the example project.
Hmm, it doesn't reproduce on iOS 11 but reproduces on iOS 10.
No, it's not fixed yet. It would require significant changes in the visibility checker. Workaround is to use grey_scrollInDirectionWithStartPoint
until we can get to it.
The last time I looked there, I appeared to me that the logic is overly complex for what it attempts to achieve.
With safe areas becoming more and more prevalent, it might be a good time to both look into simplifing the code and update the logic to support this concept.
But there is something about the safe area that throws off the algorithm of visibility, and that masks the problem. This is why I asked if it had been fixed. Perhaps a different bug.
Demo project: https://github.com/wix/EGTabScrollTest
I have the most basic of view hierarchy—a tableview (scroll view) that is embedded in a navigation controller and tab bar controller. As any proper app should, the tab bar and navigation bar are translucent, and are put on top of the table view. This is countered by iOS by setting top and bottom content offset.
It seems Earl Grey does not take this very common pattern into account. It attempts to scroll from the bottom bar, instead of starting the touches from above it (by taking into account the bottom content inset).
See attached project. When tested under iOS 10, it will display the touches Earl Grey simulates.