-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Android Matchers Need To Match More Than Just Visible Elements #1185
Comments
@amitdwix @rotemmiz I think this is a bug. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
+1 confirmed, tested with 12.1.3 |
Hey @RyanThomas73, I am trying to find an example to the issue you described. The Detox test suite has something similar (a list view with only a few items visible, but all exist in view hierarchy), this test passes on RN57, but fails in 58 and 59 AFAIK (please correct me if I'm wrong @d4vidi). The issue on later versions of RN is related to facebook/react-native#23870 and needs to be addressed in react native itself. |
Hi @rotemmiz The most common example I have of this that are problematic to me are custom dialog components that use absolute positioning to cover the screen. I'll reach a point in my test where I need to confirm that my view hierarchy is in a certain state (e.g. the login form is in the hierarchy) but all of the views in the screen are completely covered by the absolute positioned views that compose the dialog. When I have some available time I'll retest using RN 0.59 and Detox v12 to see if I still encounter the same problems. I suspect I will since the detox matcher logic is still coded to only return views with effective visibility of Visible. It looks like they were set to search for views with only effective visibility of Visible in this PR: |
@RyanThomas73 is there a workaround you've found in the meantime? |
@fancychimp Sorry, no work around that I've found. We currently have a gap in our test coverage that we left open until this is resolved for Android. |
Thanks for your reply, same here 😢 Hopefully this will be addressed soon. |
@RyanThomas73 I'd like to better understand your use case, if that's ok -- in what exact way do you have some of your views invisible, or partly visible? Also, what's the reasoning behind inspecting views that are hidden by a dialog - wouldn't it make sense to first complete the interaction with the dialog and then go back to the origin screen (e.g. login form)? I believe a picture's worth a thousand words in this case. |
@d4vidi, I'm not @RyanThomas73 but I'll share my use case: In our app, we have a screen that contains an input for a phone number. Once that input is tapped, the number keyboard is brought up. The exact step is |
@fancychimp thanks for the input! To be sure I'm not missing something here - when the keyboard pops up, it usually pops up over the phone number input - or alternatively, pushes it away from the visible viewport? (meaning, the screenshot was taken only after you've manually scrolled back up...) |
@d4vidi it does not. This is a screenshot at the |
@fancychimp I agree, yet it seems then that your problem is different seeing that the numbers input is fully visible. |
@d4vidi even if I try to precisely click on the input's coordinates using |
Using RN 0.62 & react-navigation 5.X androidx.test.espresso.base.DefaultFailureHandler$AssertionFailedWithCauseError: 'not is displayed on the screen to the user' doesn't match the selected view. No issues on iOS. In our case it is used only for convenience, for smart navigation between screens. But it would be nice to get it finally fixed. |
+1 I have a horizontal and paging FlatList and list items that are not visible are considered visible on Android. The Quick note: iOS uses
If not, at least the feature would be on parity on both platforms. HTH |
Is this bug fix still in the works? |
+1 |
1 similar comment
+1 |
Any updates on this? Still seeing this issue somehow in 2023 |
@andy-lawler-sbg I'm also experiencing this issue. could you find a work around? |
sadly not |
up |
up |
We are facing this issue only in the GitHub actions job 🤔 |
That sounds directly related to facebook/react-native#23870, which differs from the OP. |
I'd really like to pick this up for fixing in the near future, but I fail to see why globally asserting for effective-visibility using Espresso's
This is definitely an issue for the |
up |
Is there any fix for this issue? Assertions
Error
|
@LahiruRajapaksha the -await waitFor(element(by.id('cancelBtn'))).toBeVisible(); // Up to this the tests are passing
+await waitFor(element(by.id('cancelBtn'))).toBeVisible().withTimeout(MY_TIMEOUT); // Up to this the tests are passing Meaning, a view with In any case, why not use // Synchronized => Recommended
await expect(element(by.id('cancelBtn'))).toBeVisible();
// Unsynchronized => Discouraged, but correct:
await waitFor(element(by.id('cancelBtn'))).toBeVisible().withTimeout(MY_TIMEOUT); |
Description
Android matchers only match visible elements. This deviates from the expected behavior and from the behavior when running on iOS.
Steps to Reproduce
Setup a sample app that has an element that will be in the view hierarchy but not considered visible. For example a view that is covered by an overlay with partial transparency.
Run the
detox test -c <config>
command for an android config with an example test that has an expectation for the 'non visible' element to exist.Expected Behavior: The test passes because the element exists in the view hierarchy.
Actual Behavior: The test fails on android because the matchers in
DetoxMatcher.java
only select elements with effective visibilityVISIBLE
.Detox, Node, Device, Xcode and macOS Versions
10.0.10
0.57.8
11.6.0
Android Emulator
Windows 10 Pro v1703
Device and verbose Detox logs
Skipping full logs as they're not relevant. The specific error message when matching by test id:
The text was updated successfully, but these errors were encountered: