-
Notifications
You must be signed in to change notification settings - Fork 54
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
Accessibility parent #171
Accessibility parent #171
Conversation
I know it's missing documentation, if you like the approach, I'll add docs and resubmit. If not, we can figure out something a little different. |
Thanks for the PR @jzucker2. Perfectly reasonable to submit a WIP. What would be helpful instead of docs though would be a little bit (here in comments) about the problem that the new API's solving. We've talked about it before but formalizing it here will help me understand the request and best comment on its direction. |
This is a formal addition to Subliminal for matching and testing against elements inside a UITableViewCell. Subliminal does not have great abstraction for child and parent elements. This formalizes that in an easy API. My big concern is how I fixed the slAccessibilityIsVisible method, by comparing against UITableTextAccessibilityElement, which isn't very clean, but it was an awkward comparison there. Really looking for feedback on that. As well, this can be extended with a subclass for UICollectionViewCell, but I waited to do that until I heard about the UITableViewCell patch. And technically, this API could be extended to any elements inside another view or accessibility container. |
This is a cleaner implementation. The creation of SLAccessibilityContainer is a little awkward, but I had to get around initWithPredicate being a private method. This works though, except it struggles with isVisible because it seems to only select the mock accessibility view and not the actual view for isVisible. I fixed with a small hack but would love a stronger solution. |
…lve the elements. The superclass' implementation looks like: [self waitUntilTappable:NO thenPerformActionWithUIARepresentation:^(NSString *UIARepresentation) { isVisible = [[[SLTerminal sharedTerminal] evalWithFormat:@"%@.isVisible()", UIARepresentation] boolValue]; } timeout:0.0]; "Unknown objects" == objects of unknown classes like the accessibility elements vended by `UIWebBrowserView`. We shouldn't wait to resolve the element because `-isVisible` is supposed to evaluate the current state.
…ntations. (refs inkling#135) As a workaround for the failure of our visibility routine.
…ate. The previous delay was not long enough for the animation to complete on the iPad.
…5.1 or 7.1. (refs inkling#180) On iPads running iOS 5.1 or 7.1, `UIDevice` forgets its orientation after deactivation. This is not only unexpected but can mess with `-[SLElement isVisible]` which (as of inkling#180) falls back upon `UIAutomation`'s visibility routine if (but only if) the device is in a non-portrait orientation.
Update the copyright year.
Include collection view cell mock views in accessibility paths.
…lity Workaround the non-portrait-orientation bug in our visibility routine.
…liminal into accessibilityParent
@@ -133,7 +133,7 @@ - (BOOL)slAccessibilityIsVisible { | |||
// if another element comes before us/our parent in the array | |||
// (thus is z-ordered before us/our parent) | |||
// and contains our hitpoint, it covers us | |||
if (CGRectContainsPoint([element accessibilityFrame], testPoint)) return NO; | |||
if (![NSStringFromClass([element class]) isEqualToString:@"UITableTextAccessibilityElement"] && CGRectContainsPoint([element accessibilityFrame], testPoint)) return NO; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the one issue I haven't been able to figure out for myself.
The failure is from lack of documentation, not any compilation/test failures. |
I'm closing this pull request in favor of a cleaner implementation that I just submitted: #190 |
This is mostly a rough draft, wanted to see what you thought of this API for matching child elements.