Skip to content

Conversation

@Dan-Maor
Copy link
Collaborator

… based due to scrolling regression

It appears as if in some instances the recently merged payload-based snapshot comparison method does not return the correct results required for scrolling in TableViews (facebookarchive#879).

From what I saw, sometimes the extracted payload values of the matching snapshot does not match the one of the original XCUIElement, and thus the calculated UID does not match and the scrolling does not stop at the required location.

This PR reverts the fb_framelessFuzzyMatchesElement method to the previous property-based comparison implementation.

@jsf-clabot
Copy link

jsf-clabot commented Nov 29, 2018

CLA assistant check
All committers have signed the CLA.

inline static BOOL isNilOrEmpty(id value)
{
if ([value respondsToSelector:@selector(length)])
return [(NSData*)value length] == 0;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why it should be NSData instance if it responds to length?

isNilOrEmpty(self.value) && isNilOrEmpty(self.placeholderValue))
return [self.wdUID isEqualToString:snapshot.wdUID];
return self.elementType == snapshot.elementType &&
valuesAreEqual(self.identifier, snapshot.identifier) &&

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please align operators properly

@Dan-Maor
Copy link
Collaborator Author

I've addressed the comments, can you please review it again?


inline static BOOL isNilOrEmpty(id value)
{
if ([value isKindOfClass:NSClassFromString(@"NSString")]) {
Copy link

@mykola-mokhnach mykola-mokhnach Nov 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Id' rather use respondsToSelector/performSelector

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is that performSelector isn't compatible with primitive return types, I've committed that approach by mistake.

Do you think I should try using NSInvocation?

Copy link

@mykola-mokhnach mykola-mokhnach Nov 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is that a problem? you can still call integerValue from the resulting object

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried it, using it is akin to attempting to perform a selector on an object with the address of the returned value.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then let be stay like it is now. Anyway, these properties are only strings

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But replace NSClassFromString(@"NSString") with NSString.class

@mykola-mokhnach mykola-mokhnach merged commit 9d2c32a into appium:master Nov 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants