-
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
Workaround the non-portrait-orientation bug in our visibility routine. #180
Conversation
Cool I can confirm this fixes the failing tests in the sample project that reproed the bug. |
For the waitUntil(^BOOL{
return [[UIDevice sharedDevice] orientation] == orientation;
}, 4); void waitUntil(BOOL (^waitBlock)(void), const NSTimeInterval timeout)
{
NSCParameterAssert(waitBlock);
NSCParameterAssert(timeout > 0);
NSTimeInterval timeWaited = 0;
while (true) {
__block BOOL waitCondition = NO;
dispatchSyncMainQueueIfNecessary(^{
waitCondition = waitBlock();
});
if (waitCondition) {
break;
} else if (timeWaited >= timeout) {
NSCAssert(@"Timeout exception", @"Hit timeout waiting for an event");
} else {
static const NSTimeInterval sleepInterval = 0.3;
[NSThread sleepForTimeInterval:sleepInterval];
timeWaited += sleepInterval;
}
}
}
void dispatchSyncMainQueueIfNecessary(void (^block)(void))
{
NSCParameterAssert(block);
if ([NSThread isMainThread]) {
block();
} else {
dispatch_sync(dispatch_get_main_queue(), ^{
block();
});
}
} |
…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 #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.
Oh, I think that the orientation does reliably update to that set--within the old time interval, actually, as the rotation test passes just fine. I just want to make sure that the rotation animation completes by the time that I'm not sure why the tests failed the last time, but I don't think it was due to the orientation not being set right. |
Found out why they failed before--on iOS 5.1 and 7.1, iPads forget their orientation when deactivated! The orientation actually becomes That's why this test run failed--when EDIT: Since this comment is linked from the commit history, I've clarified that it is iPads running iOS 5.1 or 7.1 that exhibit this issue. |
On iOS 5.1, `UIDevice` forgets its orientation after deactivation. This is not only unexpected but can mess with `-[SLElement isVisible]` which (as of #180) falls back upon `UIAutomation`'s visibility routine if (but only if) the device is in a non-portrait orientation.
Aaand |
I wasn't able to replicate it, but maybe calling |
Further clarification: I see I don't doubt that it might work without the reset in some circumstances--in this run, some of the visibility test cases failed in a way that would suggest that the orientation had been forgotten, but not all, and Calling |
…5.1 or 7.1. (refs #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 #180) falls back upon `UIAutomation`'s visibility routine if (but only if) the device is in a non-portrait orientation.
Workaround the non-portrait-orientation bug in our visibility routine.
While we work on #135, the workaround described on that bug should make it into 1.1. cc @MaxGabriel