Error copying attributes #372

Open
toejough opened this Issue Nov 15, 2016 · 61 comments

Projects

None yet
@toejough

The same error under the same conditions as #357. Opening a new issue because that was closed as resolved by the author after the last visibility fix, so I'm assuming that this is a related, but different, root cause.

Relevant log:

[HTTP] --> GET /wd/hub/session/d0652778-1c1a-40ef-a61c-93e2674bad8b/source {}
[MJSONWP] Calling AppiumDriver.getPageSource() with args: ["d0652778-1c1a-40ef-a61c-9...
[debug] [XCUITest] Executing command 'getPageSource'
[JSONWP Proxy] Proxying [POST /source] to [POST http://localhost:8100/session/C34425C6-49B2-47B2-A2DC-894EF06195ED/source] with no body
[debug] [WebDriverAgent] Sim: Nov 14 09:39:09 vision XCTRunner[45364]: Enqueue Failure: UI Testing Failure - Failure fetching attributes for element <XCAccessib
ilityElement: 0x61000024c510> Device element: Error Domain=XCTestManagerErrorDomain Code=13 "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} <unknown> 0 1

I'm happy to try any suggested code edits, but I don't know enough about obj-c or XCUI test itself to dig around too much on my own at the moment.

I'd also be happy to have missed a step in updating this project under Appium. I've followed the steps I outlined for a successful update in #317, as well as here and here

@mykola-mokhnach
Contributor

Try to merge this PR to your local source and then add waitForNoAnimationsActive API call before to locate the corresponding element. It looks like XCTest does not like when one reads attributes while on-screen animation is active in the corresponding container. That is why it is necessary to make sure all the animations have been finished before to locate the corresponding element and read its attributes.

@toejough

Thanks! I'll give that a shot today!

@toejough
toejough commented Nov 16, 2016 edited

Nope.

I called that API before every call to page source, verified I got 200's back, and I still got

[HTTP] --> GET /wd/hub/session/c69af69b-91bf-4cda-b216-4eaa53bfcc7d/source {}
[MJSONWP] Calling AppiumDriver.getPageSource() with args: ["c69af69b-91bf-4cda-b216-4...
[debug] [XCUITest] Executing command 'getPageSource'
[JSONWP Proxy] Proxying [POST /source] to [POST http://localhost:8100/session/98821366-F49B-4B0C-9355-BD1EF1B0DEC6/source] with no body
[debug] [XCUITest] Waiting for WebDriverAgent server to finish loading...
[debug] [WebDriverAgent] Sim: Nov 16 15:04:04 vision XCTRunner[5398]: Enqueue Failure: UI Testing Failure - Failure fetching attributes for element <XCAccessibilityElement: 0x61000025af70> Device element: Error Domain=XCTestManagerErrorDomain Code=13 "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} <unknown> 0 1

This particular spot is a gmail auth screen in a webview - there's really nothing animating.

The odd thing is that when this happens, subsequent page source requests go through immediately. If it helps debugging, the page source in this case is here.

@toejough

screenshot to go along with the source:
screen shot 2016-11-16 at 3 18 44 pm

@mykola-mokhnach
Contributor

What if you just add hardcoded sleep to make sure the webview has been successfully loaded before invoking getPageSource?

@marekcirkos marekcirkos changed the title from Error copying attributes (still) to Error copying attributes Nov 17, 2016
@marekcirkos
Contributor

@toejough Can you change this method too always return NO and check if you still having this error?

@toejough

always returning NO got me through my login screens so fast I wasn't ready for it! I've been trying to follow the visibility conversation - does this mean that there are some other checks to add to that method?

@toejough

Personally, I can live with this. any incorrect visibility states that arise in my test code can be dealt with much more easily than those long timeouts.

Thank you very much for your attention and work on this!!

@muratme
muratme commented Dec 5, 2016

any update about this issue?

@prahlad06

Hi all,

Any update for fixing of this issue. Our Automation is stuck due to this.

@marekcirkos
Contributor

@prahlad06, @muratme Still in progress. You could help us by creating test case that will raise this issue in situation you are facing.

@mykola-mokhnach
Contributor

This is what I did for my local source and I don't see that bloody error anymore. Please try this patch for your local WDA sources and see whether the problem is fixed and there are no new issues pop up:

File WebDriverAgentLib/Categories/XCUIElement+FBIsVisible.m

replace the content of (BOOL)fb_isVisible method with

- (BOOL)fb_isVisible
{
  return !CGRectIsEmpty(self.frame) && !CGRectIsEmpty(self.visibleFrame);
}
@mykola-mokhnach
Contributor

I'll create a PR if you confirm the fix works and does not create additional problems with visibility detection.

@toejough
toejough commented Dec 6, 2016

ooh, I'll give this one a try today.

@marekcirkos
Contributor

@mykola-mokhnach You will definitely have problems with iOS 9.x. As I already tried similar approach. Main problem was that lots of invisible cell were reported with frames in top right corner with proper size.

However I think in iOS 10.x it has good chance of working as Apple stopped reporting weird cell cases.

@mykola-mokhnach mykola-mokhnach referenced this issue in mykola-mokhnach/Appium-iOS-Inspector Dec 7, 2016
Closed

Error after upgrading the Appium to 1.6.2. #13

@mykola-mokhnach
Contributor

@marekcirkos What if we check the actual OS version and use the current approach for the old version only (9.X)? Anyway, more than 80% of WDA users already run their tests on 10.0+.

@mykola-mokhnach
Contributor

@toejough did the patch work for you?

@mykola-mokhnach
Contributor

@marekcirkos I did a small investigation on visibility detection. Actually, I see two problematic areas now.
The first situation is when an element is outside the viewport, like
1
This can be potentially solved by analysing main window frame size and check whether it intersects with target element's frame, but XCTest also sometimes logs errors when I try to receive application property from a snapshot.

The second situation is the most tricky one:
2
The element here is just covered by another element. I have no idea about how to reliably detect visibility of such element properly, even having z-index property available.

@mykola-mokhnach
Contributor

We might also rely on hittable option of XCUIElement class, but there is no such option for snapshots, which means we'll need to resolve the whole tree (or big part of it) to show visibility attribute value for /source command output or to generate an xml tree (since each node there also has visible attribute set), which is sloooow.

@Blinkk
Blinkk commented Dec 7, 2016 edited

@mykola-mokhnach I am also having this issue with some additional strange behavior and I am a bit confused.

I am able to locate and interact with an element using a custom method in one area of the application I am testing, but am seeing some strange behavior using almost identical methods in other parts of the application. Here is the method that works:

public IWebElement GetMenuElement(int index)
{
    try
    {
        return driver.FindElement(By.XPath(
            string.Format("//XCUIElementTypeApplication[1]/XCUIElementTypeWindow[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]" +
            "/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]" +
            "/XCUIElementTypeTable[1]/XCUIElementTypeCell[{0}]/XCUIElementTypeButton[1]", index)));
    }
    catch (Exception e)
    {
        Debug.WriteLine("Failed to GetMenuElement(" + index + ") in " + this.ToString());
        throw e;
    }
}

This selects a button from a small list of buttons within a hamburger menu and does so flawlessly. The following method attempts to do essentially the same thing (however, in a larger list of elements) and gets stuck in an loop of POST requests and eventually fails.

public IWebElement GetProductQuickCartElement(int index)
{
    try
    {
        return driver.FindElement(By.XPath(
            string.Format("//XCUIElementTypeApplication[1]/XCUIElementTypeWindow[1]/XCUIElementTypeOther[1]" +
            "/XCUIElementTypeOther[1]/XCUIElementTypeOther[2]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]" +
            "/XCUIElementTypeOther[1]/XCUIElementTypeTable[1]/XCUIElementTypeCell[{0}]/XCUIElementTypeButton[1]", index)));
    }
    catch (Exception e)
    {
        Debug.WriteLine("Failed to GetProductQuickCartElement(" + index + ") in " + this.ToString());
        throw e;
    }
}

A full copy of the test logs can be seen here. Note that at line 496 it successfully uses the first method to locate an element.

Additionally, using the following method (almost identical to the other two, again) I receive an error:

public IWebElement GetMenuElement(int index)
{
    try
    {
        return driver.FindElement(By.XPath(
            string.Format("//XCUIElementTypeApplication[1]/XCUIElementTypeWindow[1]" +
            "/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]" + 
            "/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeTable[1]/XCUIElementTypeCell[{0}]", index)));
    }
    catch (Exception e)
    {
        Debug.WriteLine("Failed to GetMenuElement(" + index + ") in " + this.ToString());
        throw e;
    }
}

Error:
XCTRunner[1068]: Enqueue Failure: UI Testing Failure - Failure fetching attributes for element <XCAccessibilityElement: 0x608000248a30> Device element: Error Domain=XCTestManagerErrorDomain Code=13 "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} <unknown> 0 1
Full log here.

I have tried using the workarounds mentioned in this thread (the patch mentioned by @mykola-mokhnach) and got this:

  • The logs for the test that threw the "UI Testing Failure" error shows this
  • The test that was looping POST requests shows the same behavior.

I would appreciate any help anyone may be able to offer in this area because while I have ways of working around this by getting the entire list of elements in a List<> by using "ClassName" attribute and selecting one by index, this is incredibly slow as some of the lists of elements I am working with can be very large. These custom methods speed up my tests significantly (which is why I created them) and I would like to be able to continue using them.

@mykola-mokhnach mykola-mokhnach referenced this issue in mykola-mokhnach/Appium-iOS-Inspector Dec 7, 2016
Closed

Issues capturing view if it contains a high amount of complexity. #14

@jediboy
jediboy commented Dec 8, 2016

So for me, I've narrowed this issue down to table views that do paginated scrolling. We hit the server for the first 10 rows of data for the table and as you scroll down we hit the server to get the next 10 rows and so on until all of the rows have been retrieved.

From what I can tell, there seems to be some sort of automatic scrolling happening behind the scenes that is attempting to scroll the view to get all of the elements. The view in the app doesn't appear to be physically scrolling, but it is loading more elements. I know this because I can see the calls happening to the server and the appium inspector will eventually respond with hundreds of table cells even though I haven't physically done any scrolling in the app to retrieve the additional data rows. Until this auto scrolling process completes, appium appears to be "hung" and you can't find any other elements.

I'm not sure what I can do to get around this situation yet, but it's pretty consistent for me. Is there any way to stop this auto scrolling from happening? For the time being, I can add try/catches in my code with hard coded wait times, but that's a pretty poor way to do automated testing :/

@mykola-mokhnach
Contributor

@jediboy I've prepared a PR, which allows to wait properly until an animation is finished to avoid hardcoded timeouts. You can try to apply that patch to your local codebase and check whether it solves the issue with your tests.

@jediboy
jediboy commented Dec 8, 2016

Thanks @mykola-mokhnach .. assuming I applied the PR correctly, I'm still seeing that message in the log. Any idea why it's trying to do that auto scrolling of the view? My test is trying to tap on the first cell in the table but it's super slow because it loading every cell before it tries to tap the cell that I want.

@mykola-mokhnach
Contributor

@jediboy It's not just enough to apply it. You need to call this API before you do element lookup to make sure the animation is finished. It just allows to replace hardcoded sleeps with timed sleeps.

Regarding scrolling. WDA will try to automatically scroll to reach the destination cell if you try to click it and it is currently invisible. So try to scroll the view yourself first to make sure the destination cell is visible.

@KBhatti
KBhatti commented Dec 10, 2016

@mykola-mokhnach what if the cell is currently visible but I still see this issue? Is that also something WDA is trying to come up with a fix for? Also, any ETA for that please?

@marekcirkos
Contributor

@KBhatti Less problematic visibility check is definitely what we want to achieve. However most likely it will take some time. As everything in OpenSource there is no ETA for this as people spend their private live time on this. Feel free to join discussion or pop some PRs, if you have some ideas.

@muratme
muratme commented Dec 12, 2016 edited

@marekcirkos

`[Xcode] 2016-12-12 16:30:50.398 xcodebuild[68192:3423372] Error Domain=IDETestOperationsObserverErrorDomain Code=5 "Early unexpected exit, operation never finished bootstrapping - no restart will be attempted" UserInfo={NSLocalizedDescription=Early unexpected exit, operation never finished bootstrapping - no restart will be attempted}

[Xcode]
Testing failed:
Test target WebDriverAgentRunner encountered an error (Early unexpected exit, operation never finished bootstrapping - no restart will be attempted)

[Xcode] ** TEST FAILED **

[XCUITest] xcodebuild exited with code '65' and signal 'null'
[XCUITest] Error: xcodebuild failed with code 65
at SubProcess. (../../lib/webdriveragent.js:332:25)
at emitTwo (events.js:106:13)
at SubProcess.emit (events.js:191:7)
at ChildProcess. (../../lib/teen_process.js:197:14)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
Error: xcodebuild failed with code 65
at SubProcess. (../../lib/webdriveragent.js:332:25)
at emitTwo (events.js:106:13)
at SubProcess.emit (events.js:191:7)
at ChildProcess. (../../lib/teen_process.js:197:14)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
[XCUITest] Shutting down sub-processes
[XCUITest] Shutting down Logger process (pid 68197)
[XCUITest] System log exited with code '0'
[debug] [XCUITest] Running ios real device reset flow
[debug] [XCUITest] Resetting simulator
[debug] [iOSLog] Stopping iOS log capture
(node:68124) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 4): Error: Can't stop process; it's not currently running
[MJSONWP] Encountered internal error running command: Error: xcodebuild failed with code 65
at SubProcess. (../../lib/webdriveragent.js:332:25)
at emitTwo (events.js:106:13)
at SubProcess.emit (events.js:191:7)
at ChildProcess. (../../lib/teen_process.js:197:14)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)`

@marekcirkos
Contributor

@muratme That is unrelated. This is Xcode issue starting XCUITest.

@mykola-mokhnach
Contributor
mykola-mokhnach commented Dec 12, 2016 edited

For now I came up with this quick and dirty verification for visibility detection:

  return !CGRectIsEmpty(self.frame) && !CGRectIsEmpty(self.visibleFrame) && (CGRectIntersectsRect(self.visibleFrame, self.application.frame) || ((self.application.interfaceOrientation == UIInterfaceOrientationLandscapeLeft || self.application.interfaceOrientation == UIInterfaceOrientationLandscapeRight) && self.application.frame.size.height > self.application.frame.size.width && CGRectIntersectsRect(self.visibleFrame, CGRectMake(0, 0, self.application.frame.size.height, self.application.frame.size.width))));

this also includes a workaround for XCTest bug with landscape mode. No more unexpected delays. The only problem there is that this verification cannot detect cases when one element covers another one in the UI (see my comment above with the screenshots). Probably, it would not be the case, if XCTest could properly calculate visibleFrame property of a snapshot. I have even created a separate bug for Apple, but, as usually, no one knows when it could be fixed (if it can be fixed).

@derinbay

That's working. Thanks for the workaround.

@KBhatti
KBhatti commented Dec 13, 2016

@derinbay did you have to make that code change within the Appium code, or your app's source code?

@derinbay
derinbay commented Dec 13, 2016 edited

@KBhatti I've changed the WebDriverAgent code that @mykola-mokhnach mentioned on the his last comment. The file is at /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgentLib/CategoriesXCUIElement+FBIsVisible.m

You don't need to change anything within your app's code for this one.

@KBhatti
KBhatti commented Dec 13, 2016

so @mykola-mokhnach I think we could do this change on our local machines...but if we run the same tests on a CI tool (Travis CI VM) for instance..this may not be doable?

@derinbay

This is just a workaround for you to continue development. You need to change this code line on all computers with appium on ci infrastracture, manually. If you have hundreds, you can try to fork the project and give that dependency. Or you can wait a for a fixed version.

@KBhatti
KBhatti commented Dec 13, 2016

Thanks @derinbay yeah seems to be enough work..I think from what I know..no one knows of any timeframe of when Appium would come out for a fix for this..

@jlipps
jlipps commented Dec 13, 2016

@KBhatti in this case it's not an Appium issue. We're waiting on a fix in this project. If you want to help research a fix, that'd be helpful.

@mykola-mokhnach mykola-mokhnach referenced this issue in appium/appium Dec 14, 2016
Closed

Freeze when using wait #7533

@KBhatti
KBhatti commented Dec 14, 2016 edited

@jlipps does 1.6.3 fix this issue as well? I guess this is what I was referring to on the other thread.

It may be unrelated so if this is not yet in 1.6.3 thats fine..was just making sure

@jlipps
jlipps commented Dec 14, 2016

I don't believe that @mykola-mokhnach's hack is in Appium. It would first need to be published in WDA.

@marekcirkos
Contributor

@mykola-mokhnach This is awesome. visibility checks didn't work with views being covered by other views anyway. Can you pop a PR? I'll check that on our tests as well.

@mykola-mokhnach
Contributor
mykola-mokhnach commented Dec 14, 2016 edited

@marekcirkos I'd like to have this PR merged first, since the current implementation looks a bit ugly with this orientation workaround. And the mentioned PR contains one useful method to make it looking better: FBAdjustDimensionsForApplication

I would very appreciate it if you could dedicate some time to review at least this PR.

@wangtao169447
wangtao169447 commented Dec 20, 2016 edited

Hi all,

Any update for fixing of this issue. Our Automation is stuck due to this.

hoping for your help,thx
@mykola-mokhnach
- (BOOL)fb_isVisible
{
return !CGRectIsEmpty(self.frame) && !CGRectIsEmpty(self.visibleFrame) && (CGRectIntersectsRect(self.visibleFrame, self.application.frame) || ((self.application.interfaceOrientation == UIInterfaceOrientationLandscapeLeft || self.application.interfaceOrientation == UIInterfaceOrientationLandscapeRight) && self.application.frame.size.height > self.application.frame.size.width && CGRectIntersectsRect(self.visibleFrame, CGRectMake(0, 0, self.application.frame.size.height, self.application.frame.size.width))));
}
i also change the fun,but did't work .

still have this problem:
[debug] [WebDriverAgent] Sim: Dec 20 15:53:26 mbd-ios-qa XCTRunner[42746]: Enqueue Failure: UI Testing Failure - Failure fetching attributes for element <XCAccessibilityElement: 0x6000002504a0> Device element: Error Domain=XCTestManagerErrorDomain Code=13 "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} <unknown> 0 1

@KBhatti
KBhatti commented Dec 22, 2016

@marekcirkos @mykola-mokhnach are we planning to have this PR merged anytime soon? If so..is it going to be with Appium 1.6.4 or something?

@KBhatti
KBhatti commented Jan 5, 2017

@mykola-mokhnach I know we can apply this patch locally but any idea if any future release of Appium will include this? Only reason I ask is that I would want to run this on CI as well..other than just locally.

@marekcirkos
Contributor

@KBhatti We don't have proper solution yet.

@KBhatti
KBhatti commented Jan 5, 2017

@marekcirkos that is fine I understand I can workaround with @mykola-mokhnach solution locally for the time being (I'm thinking thats what a lot of the folks are doing anyway). But whenever we do have a proper solution is it going to be part of a future Appium release?

@marekcirkos
Contributor

If they pick it up, yes :)

@KBhatti
KBhatti commented Jan 7, 2017

@marcelerz you don't look too optimistic of it happening anytime soon..if at all :-)

@limitcracker
limitcracker commented Jan 10, 2017 edited

Hi @marekcirkos @mykola-mokhnach and all

We have applied this patch

- (BOOL)fb_isVisible
{
return !CGRectIsEmpty(self.frame) && !CGRectIsEmpty(self.visibleFrame) && (CGRectIntersectsRect(self.visibleFrame, self.application.frame) || ((self.application.interfaceOrientation == UIInterfaceOrientationLandscapeLeft || self.application.interfaceOrientation == UIInterfaceOrientationLandscapeRight) && self.application.frame.size.height > self.application.frame.size.width && CGRectIntersectsRect(self.visibleFrame, CGRectMake(0, 0, self.application.frame.size.height, self.application.frame.size.width))));
}

It seems to solve the animation problem but it introduces another issue. It finds all the elements visible even if they are not displayed in the view port. In our case we check if an element is visible and if not we scroll down or up accordingly until it's visible. Therefore we cannot apply this solution.

Any updates about this issue? It's kind of blocking since we forced to introduce a lot of static delays in our tests and even with that sometimes our tests are hanging.

@mykola-mokhnach
Contributor

@limitcracker This problem with visibility detection has been already described above. You either have a workaround, that does not freeze your tests, but cannot detect invisible elements with 100% reliability or the current one, which creates unexpected delays.
There are no other solutions we can provide right now. You can ping οΏ½Apple though, so they fix that thing in XCTest for us.

@vikramvi

@marekcirkos please find consistent steps to reproduce the issue

appium/appium#7034 (comment)

@Nischalapp

@mykola-mokhnach Thanks so much your solution is working for me with Appium 1.6.3

Guys who is having problem use below code given by @mykola-mokhnach

/**

  • Copyright (c) 2015-present, Facebook, Inc.
  • All rights reserved.
  • This source code is licensed under the BSD-style license found in the
  • LICENSE file in the root directory of this source tree. An additional grant
  • of patent rights can be found in the PATENTS file in the same directory.
    */

#import "XCUIElement+FBIsVisible.h"

#import "XCElementSnapshot+FBHelpers.h"
#import "XCTestPrivateSymbols.h"

@implementation XCUIElement (FBIsVisible)

  • (BOOL)fb_isVisible
    {
    if (!self.lastSnapshot) {
    [self resolve];
    }
    return self.lastSnapshot.fb_isVisible;
    }

@end

@implementation XCElementSnapshot (FBIsVisible)

  • (BOOL)fb_isVisible
    {

    return !CGRectIsEmpty(self.frame) && !CGRectIsEmpty(self.visibleFrame) && (CGRectIntersectsRect(self.visibleFrame, self.application.frame) || ((self.application.interfaceOrientation == UIInterfaceOrientationLandscapeLeft || self.application.interfaceOrientation == UIInterfaceOrientationLandscapeRight) && self.application.frame.size.height > self.application.frame.size.width && CGRectIntersectsRect(self.visibleFrame, CGRectMake(0, 0, self.application.frame.size.height, self.application.frame.size.width))));
    // if (CGRectIsEmpty(self.frame) || CGRectIsEmpty(self.visibleFrame)) {
    // /*
    // It turns out, that XCTest triggers
    // Enqueue Failure: UI Testing Failure - Failure fetching attributes for element
    // <XCAccessibilityElement: 0x60000025f9e0> Device element: Error Domain=XCTestManagerErrorDomain Code=13
    // "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} 0 1
    // error in the log if we try to get visibility attribute for an element snapshot, which does not intersect with visible appication area
    // or if it has zero width/height. Also, XCTest waits for 15 seconds after this line appears in the log, which makes /source command
    // execution extremely slow for some applications.
    // */
    // return NO;
    //
    //
    // }
    // return [(NSNumber *)[self fb_attributeValue:FB_XCAXAIsVisibleAttribute] boolValue];
    }

@end

Paste in ur file XCUIElement+FBIsVisible.m above code.

@mykola-mokhnach
Contributor

@Nischalapp I'm currently working on more flexible solution

you can merge the patch with your local source and set the "ALTERNATIVE_VISIBILITY_DETECTION" environment variable to "YES" to test the stuff.

@Nischalapp

@mykola-mokhnach how to set this flag and where to set this ALTERNATIVE_VISIBILITY_DETECTION

@mykola-mokhnach
Contributor

This is the same workaround, but just more elegant. Please update WDA to the most recent version before applying it:

@@ -9,6 +9,7 @@
 
 #import "XCUIElement+FBIsVisible.h"
 
+#import "FBMathUtils.h"
 #import "XCElementSnapshot+FBHelpers.h"
 #import "XCTestPrivateSymbols.h"
 
@@ -29,18 +30,10 @@
 - (BOOL)fb_isVisible
 {
   if (CGRectIsEmpty(self.frame) || CGRectIsEmpty(self.visibleFrame)) {
-    /*
-     It turns out, that XCTest triggers
-       Enqueue Failure: UI Testing Failure - Failure fetching attributes for element
-       <XCAccessibilityElement: 0x60000025f9e0> Device element: Error Domain=XCTestManagerErrorDomain Code=13
-       "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202} <unknown> 0 1
-     error in the log if we try to get visibility attribute for an element snapshot, which does not intersect with visible appication area
-     or if it has zero width/height. Also, XCTest waits for 15 seconds after this line appears in the log, which makes /source command
-     execution extremely slow for some applications.
-     */
     return NO;
   }
-  return [(NSNumber *)[self fb_attributeValue:FB_XCAXAIsVisibleAttribute] boolValue];
+  CGSize screenSize = FBAdjustDimensionsForApplication(self.application.frame.size, self.application.interfaceOrientation);
+  return CGRectIntersectsRect(self.visibleFrame, CGRectMake(0, 0, screenSize.width, screenSize.height));
 }
 
 @end

Known issues (all caused by XCTest bug about visibleFrame property evaluation):

  • Off-screen table cells are detected as visible
  • Invisible non off-screen non-zero-size UI elements covered by another elements/views are detected as visible
@ptsiakos77
ptsiakos77 commented Feb 3, 2017 edited

@mykola-mokhnach We tried this solution in master branch of WDA but we encountered many errors of type:

_[MJSONWP] Encountered internal error running command: ProxyRequestError: Could not proxy command to remote server. Original error: Error: ESOCKETTIMEDOUT
at JWProxy.proxy$ (../../../lib/jsonwp-proxy/proxy.js:126:13)
at tryCatch (/usr/local/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:67:40)
at GeneratorFunctionPrototype.invoke [as invoke] (/usr/local/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:315:22)
at GeneratorFunctionPrototype.prototype.(anonymous function) [as throw] (/usr/local/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.jsπŸ’―21)
at GeneratorFunctionPrototype.invoke (/usr/local/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:136:37)
03/02/17 14:41:33 Stevia [RC IOSController$$EnhancerBySpringCGLIB$$d967cdf6@a7b8] ERROR - IOSLogger - An unknown server-side error occurred while processing the command. Original error: Could not proxy command to remote server. Original error: Error: ESOCKETTIMEDOUT (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 242.14 seconds

Usually these errors happened when we supplied values in search of filter input fields that trigger a search or filter action. The strange think is that with the WDA version that is embedded with Appium 1.6.3 and the original patch we didn't have these kind of errors so often and especially in input search fields.
You can find below thew device log file from a crash:
deviceLog.txt

Also we applied the patch of your branch with ALTERNATIVE_VISIBILITY_DETECTION variable but with no luck.
We set it as env in the build settings of the WebDriveAgentRunner (see attachments)
screen shot 2017-02-03 at 11 27 41 am

Have we missed something?

@Nischalapp
@ptsiakos77

I am not sure that it solves the problems mentioned since from what it seems has not included something new from WDA side regarding the mentioned issues

@Nischalapp
@KBhatti
KBhatti commented Feb 4, 2017

@Nischalapp @ptsiakos77 is appium 1.6.4 going to solve this issue? I would be surprised if that were the case since I thought this supposed to be a WDA fix.

@ptsiakos77 @mykola-mokhnach what should we try for now. Just have the latest appium version 1.6.3 and and inside it delete the wda and install the latest wda again using "npm install -g xcuitestdriver' ? @mykola-mokhnach should I try your latest elegant version..and with or without the "ALTERNATIVE_VISIBILITY_DETECTION" env. variable in xcode?
Appreciate and thanks in advance!

@Nischalapp
@KBhatti
KBhatti commented Feb 17, 2017

@ptsiakos77 @mykola-mokhnach what should we try for now. Just have the latest appium version 1.6.3 and and inside it delete the wda and install the latest wda again using "npm install -g xcuitestdriver' ? @mykola-mokhnach should I try your latest elegant version..and with or without the "ALTERNATIVE_VISIBILITY_DETECTION" env. variable in xcode?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment