Webdriveragent: Xcode 9 Support
Time to start working on Xcode 9 :). Please raise any issues here. I'll keep updating todo list to reflect known, left issues.
[x] WDA is not building
[x]
_parentElementselector is missing[x]
appWithPID:selector is missing[x]
rectrequest fails to wrap NSNumber[x] testSimpleScroll - Scrolling seems to work, but this test fails what seems to be change on how touch events are handled
[x] XCUIDeviceRotationTests - Rotation works, but
orientationproperty is not being updated,[x] testInvisibleDescendantWithXPathQuery - searched element is now considered visible.
[ ]
sourceis slow[x] performance is much worse
[x] WebView subviews are not visible
marekcirkos
All 77 comments
When trying to do anything involving numbers JSON parsing fails. For instance, getting the rect (this is from an Appium log, but you can see the URL we are hitting in WebDriverAgent, and the error we get back):
dbug JSONWP Proxy Proxying [GET /element/A6FB5912-4DC1-4CC3-A125-8913F3854717/rect] to [GET http://localhost:8100/session/B346E0B7-E439-43DD-B7AF-8DA6F32691BA/element/A6FB5912-4DC1-4CC3-A125-8913F3854717/rect] with no body
dbug JSONWP Proxy Got response with status 200: "{\n \"value\" : \"Invalid number value (infinite) in JSON write\\n\\n(\\n\\t0 CoreFoundation 0x0000000110e5779b __exceptionPreprocess + 171\\n\\t1 libobjc.A.dylib 0x00000001107b9121 objc_exception_throw + 48\\n\\t2 CoreFoundation 0x0000000110ed0b25 +[NSException raise:format:] + 197\\n\\t3 Foundation 0x000000011021e94a _writeJSONNumber + 366\\n\\t4 Foundation 0x00000001101ced22 _writeJSONValue + 495\\n\\t5 Foundation 0x000000011021e758 ___writeJSONObject_block_invoke + 176\\n\\t6 CoreFoundation 0x0000000110de61d4 -[__NSDictionaryI enumerateKeysAndObjectsWithOptions:usingBlock:] + 180\\n\\t7 Foundation 0x000000011021e35b _writeJSONObject + 483\\n\\t8 Foundation 0x000000011021e758 ___writeJSONObject_block_invoke + 176\\n\\t9 CoreFoundation 0x0000000110de61d4 -[_...
Full WebDriverAgent stack trace from error
An unknown server-side error occurred while processing the command. Original error: Invalid number value (infinite) in JSON write
(
0 CoreFoundation 0x0000000110e5779b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00000001107b9121 objc_exception_throw + 48
2 CoreFoundation 0x0000000110ed0b25 +[NSException raise:format:] + 197
3 Foundation 0x000000011021e94a _writeJSONNumber + 366
4 Foundation 0x00000001101ced22 _writeJSONValue + 495
5 Foundation 0x000000011021e758 ___writeJSONObject_block_invoke + 176
6 CoreFoundation 0x0000000110de61d4 -[__NSDictionaryI enumerateKeysAndObjectsWithOptions:usingBlock:] + 180
7 Foundation 0x000000011021e35b _writeJSONObject + 483
8 Foundation 0x000000011021e758 ___writeJSONObject_block_invoke + 176
9 CoreFoundation 0x0000000110de61d4 -[__NSDictionaryI enumerateKeysAndObjectsWithOptions:usingBlock:] + 180
10 Foundation 0x000000011021e35b _writeJSONObject + 483
11 Foundation 0x00000001101ceadf -[_NSJSONWriter dataWithRootObject:options:error:] + 124
12 Foundation 0x00000001101ce9c2 +[NSJSONSerialization dataWithJSONObject:options:error:] + 337
13 WebDriverAgentLib 0x000000012c9c0520 -[FBResponseJSONPayload dispatchWithResponse:] + 128
14 WebDriverAgentLib 0x000000012c9b93cc -[FBRoute_TargetAction mountRequest:intoResponse:] + 220
15 WebDriverAgentLib 0x000000012c9b11c4 __37-[FBWebServer registerRouteHandlers:]_block_invoke + 548
16 RoutingHTTPServer 0x000000012ca57c18 -[RoutingHTTPServer handleRoute:withRequest:response:] + 136
17 RoutingHTTPServer 0x000000012ca584fa __72-[RoutingHTTPServer routeMethod:withPath:parameters:request:connection:]_block_invoke + 47
18 libdispatch.dylib 0x00000001156abbb9 _dispatch_client_callout + 8
19 libdispatch.dylib 0x00000001156b756c _dispatch_sync_thread_bound_invoke + 119
20 libdispatch.dylib 0x00000001156abbb9 _dispatch_client_callout + 8
21 libdispatch.dylib 0x00000001156b60e2 _dispatch_main_queue_callback_4CF + 1218
22 CoreFoundation 0x0000000110e1a879 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
23 CoreFoundation 0x0000000110ddef82 __CFRunLoopRun + 2162
24 CoreFoundation 0x0000000110dde499 CFRunLoopRunSpecific + 409
25 Foundation 0x00000001101c022e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
26 Foundation 0x00000001101c0109 -[NSRunLoop(NSRunLoop) run] + 76
27 WebDriverAgentLib 0x000000012c9b01b3 -[FBWebServer startServing] + 211
28 WebDriverAgentRunner 0x000000012c9a7294 -[UITestingUITests testRunner] + 100
29 CoreFoundation 0x0000000110ddbf8c __invoking___ + 140
30 CoreFoundation 0x0000000110ddbe60 -[NSInvocation invoke] + 320
31 XCTest 0x000000011007c6e0 __24-[XCTestCase invokeTest]_block_invoke_2 + 451
32 XCTest 0x00000001100c3bed -[XCUITestContext performInScope:] + 187
33 XCTest 0x000000011007c4f8 -[XCTestCase invokeTest] + 254
34 XCTest 0x000000011007d424 __26-[XCTestCase performTest:]_block_invoke.362 + 42
35 XCTest 0x00000001100c8432 +[XCTContext runInContextForTestCase:block:] + 163
36 XCTest 0x000000011007cdc0 -[XCTestCase performTest:] + 608
37 XCTest 0x0000000110079396 __27-[XCTestSuite performTest:]_block_invoke + 295
38 XCTest 0x0000000110078f8d -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
39 XCTest 0x0000000110079171 -[XCTestSuite performTest:] + 214
40 XCTest 0x0000000110079396 __27-[XCTestSuite performTest:]_block_invoke + 295
41 XCTest 0x0000000110078f8d -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
42 XCTest 0x0000000110079171 -[XCTestSuite performTest:] + 214
43 XCTest 0x0000000110079396 __27-[XCTestSuite performTest:]_block_invoke + 295
44 XCTest 0x0000000110078f8d -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
45 XCTest 0x0000000110079171 -[XCTestSuite performTest:] + 214
46 XCTest 0x00000001100cf625 __44-[XCTTestRunSession runTestsAndReturnError:]_block_invoke + 40
47 XCTest 0x000000011008bb99 -[XCTestObservationCenter _observeTestExecutionForBlock:] + 480
48 XCTest 0x00000001100cf4c4 -[XCTTestRunSession runTestsAndReturnError:] + 281
49 XCTest 0x0000000110068d43 -[XCTestDriver runTestsAndReturnError:] + 254
50 XCTest 0x00000001100c76b7 _XCTestMain + 616
51 CoreFoundation 0x0000000110dfadcc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
52 CoreFoundation 0x0000000110ddf33b __CFRunLoopDoBlocks + 203
53 CoreFoundation 0x0000000110ddeb34 __CFRunLoopRun + 1060
54 CoreFoundation 0x0000000110dde499 CFRunLoopRunSpecific + 409
55 GraphicsServices 0x00000001140349d7 GSEventRunModal + 62
56 UIKit 0x00000001112d60b8 UIApplicationMain + 159
57 WebDriverAgentRunner-Runner 0x000000010fde4835 WebDriverAgentRunner-Runner + 6197
58 libdyld.dylib 0x0000000115721771 start + 1
)
imurchie
on 11 Jul 2017
There also seems to be a 3-5 second pause while clicking on any element. I don't have any logs or anything from that, since it doesn't produce any... just sits there and then successfully clicks.
imurchie
on 11 Jul 2017
Speaking of logging, nothing is written to the simulator logs, either. This is not a WebDriverAgent problem, of course, but annoying.
imurchie
on 11 Jul 2017
I think this is because frame is returned as Inf, which happens due to invalid snapshot. I'll add to to list just to confirm it works in the end.
marekcirkos
on 11 Jul 2017
When I was testing https://github.com/facebook/WebDriverAgent/pull/641 then I noticed the _children_ property of XCElementSnapshot always returns an empty list. This renders /source endpoint as well as xpath and class chain search to be non-functional.
mykola-mokhnach
on 12 Jul 2017
I start to suspect that we will have to drop usage of snapshots. It seems that they are not always deserialised completely (missing parent, children etc), my bet is on the fact that element queries are now executed on application side, not XCTest. So less information is transferred back.
marekcirkos
on 12 Jul 2017
@marekcirkos So how we can extract application UI tree then?
mykola-mokhnach
on 12 Jul 2017
@mykola-mokhnach Trying to figure it out :)
marekcirkos
on 12 Jul 2017
I think snapshot is mess anyways. I have seen at some point it just uses too much memory on application side. I hope new query engine is more efficient.
yaphatak
on 12 Jul 2017
@marekcirkos I've spent some time today thinking about how it is possible to implement xml tree assembling for iOS11 and got several ideas:
- transform xpath expression to predicate in runtime. This gives us fastest lookup times, however the task itself might be very complicated from implementation point of view, since it might be hardly possible (or even impossible at all) to transform complicated xpath queries into predicates. However it can be still an option, especially if we detect some simple xpath query without complex hierarchical dependencies. Another pros - we don't use snapshots at all.
- Build the xml tree based on recursive _childrenByType_ lookup query. I tried this and it looks very slow. Query resolution takes about 0.2 s for each separate node and multiplies to the overall count of nodes. Pros - it is the simplest approach to implement and it does not require snapshots
- Build the tree based on the fact, that _lastSnapshot.parent_ property still works. It is also possible to extract the unique id for each snapshot (it's a hack, but who cares :) ). This approach requires to execute only one lookup query, but then it needs time to resolve snapshots to find out who is parent of who. The overall lookup speed is supposed to be close to the lookup speed we had for the initial WDA release. This is slow, but anyway faster, than the second option. I've also prepared POC implementation in https://github.com/mykola-mokhnach/WebDriverAgent/tree/ios11_xpath
mykola-mokhnach
on 13 Jul 2017
When hitting the alert text endpoint I'm getting a WebDriverAgent exception. It seems that fb_isVisible is not found as a property?
Proxying [GET /alert/text] to [GET http://localhost:8100/session/C7B1B716-4E2A-4888-B758-CFD86C24C733/alert/text] with no body
Full stack trace:
An unknown server-side error occurred while processing the command. Selenium error: An unknown server-side error occurred while processing the command.
Original error: -[XCElementSnapshot _rootElement]: unrecognized selector sent to instance 0x6000003805b0
(
0 CoreFoundation 0x000000010e1bbc7b __exceptionPreprocess + 171
1 libobjc.A.dylib 0x000000010db1e121 objc_exception_throw + 48
2 CoreFoundation 0x000000010e2397b4 -[NSObject(NSObject) doesNotRecognizeSelector:] + 132
3 CoreFoundation 0x000000010e13f2c8 ___forwarding___ + 1432
4 CoreFoundation 0x000000010e13eca8 _CF_forwarding_prep_0 + 120
5 WebDriverAgentLib 0x0000000124b0b7dd -[XCElementSnapshot(FBIsVisible) fb_isVisible] + 333
6 WebDriverAgentLib 0x0000000124b171ab -[XCElementSnapshot(WebDriverAttributes) isWDVisible] + 43
7 WebDriverAgentLib 0x0000000124b268eb -[FBAlert text] + 523
8 WebDriverAgentLib 0x0000000124b1fe11 +[FBAlertViewCommands handleAlertTextCommand:] + 161
9 WebDriverAgentLib 0x0000000124b0d993 -[FBRoute_TargetAction mountRequest:intoResponse:] + 179
10 WebDriverAgentLib 0x0000000124b057b4 __37-[FBWebServer registerRouteHandlers:]_block_invoke + 548
11 RoutingHTTPServer 0x0000000124baac18 -[RoutingHTTPServer handleRoute:withRequest:response:] + 136
12 RoutingHTTPServer 0x0000000124bab4fa __72-[RoutingHTTPServer routeMethod:withPath:parameters:request:connection:]_block_invoke + 47
13 libdispatch.dylib 0x0000000112a477c1 _dispatch_client_callout + 8
14 libdispatch.dylib 0x0000000112a537ea _dispatch_sync_thread_bound_invoke + 119
15 libdispatch.dylib 0x0000000112a477c1 _dispatch_client_callout + 8
16 libdispatch.dylib 0x0000000112a52062 _dispatch_main_queue_callback_4CF + 1285
17 CoreFoundation 0x000000010e17ede9 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
18 CoreFoundation 0x000000010e1436a2 __CFRunLoopRun + 2162
19 CoreFoundation 0x000000010e142bb9 CFRunLoopRunSpecific + 409
20 Foundation 0x000000010d51bf7e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 274
21 Foundation 0x000000010d51be59 -[NSRunLoop(NSRunLoop) run] + 76
22 WebDriverAgentLib 0x0000000124b047a3 -[FBWebServer startServing] + 211
23 WebDriverAgentRunner 0x0000000123d07294 -[UITestingUITests testRunner] + 100
24 CoreFoundation 0x000000010e1406ac __invoking___ + 140
25 CoreFoundation 0x000000010e140580 -[NSInvocation invoke] + 320
26 XCTest 0x000000010d3d45b5 __24-[XCTestCase invokeTest]_block_invoke_2 + 451
27 XCTest 0x000000010d41c367 -[XCUITestContext performInScope:] + 183
28 XCTest 0x000000010d3d43cd -[XCTestCase invokeTest] + 254
29 XCTest 0x000000010d3d52f9 __26-[XCTestCase performTest:]_block_invoke.362 + 42
30 XCTest 0x000000010d420d94 +[XCTContext runInContextForTestCase:block:] + 163
31 XCTest 0x000000010d3d4c95 -[XCTestCase performTest:] + 608
32 XCTest 0x000000010d3d0e04 __27-[XCTestSuite performTest:]_block_invoke + 363
33 XCTest 0x000000010d3d076b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
34 XCTest 0x000000010d3d0968 -[XCTestSuite performTest:] + 239
35 XCTest 0x000000010d3d0e04 __27-[XCTestSuite performTest:]_block_invoke + 363
36 XCTest 0x000000010d3d076b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
37 XCTest 0x000000010d3d0968 -[XCTestSuite performTest:] + 239
38 XCTest 0x000000010d3d0e04 __27-[XCTestSuite performTest:]_block_invoke + 363
39 XCTest 0x000000010d3d076b -[XCTestSuite _performProtectedSectionForTest:testSection:] + 26
40 XCTest 0x000000010d3d0968 -[XCTestSuite performTest:] + 239
41 XCTest 0x000000010d427f48 __44-[XCTTestRunSession runTestsAndReturnError:]_block_invoke + 40
42 XCTest 0x000000010d3e3e38 -[XCTestObservationCenter _observeTestExecutionForBlock:] + 475
43 XCTest 0x000000010d427de7 -[XCTTestRunSession runTestsAndReturnError:] + 281
44 XCTest 0x000000010d3c04e9 -[XCTestDriver runTestsAndReturnError:] + 254
45 XCTest 0x000000010d420019 _XCTestMain + 616
46 CoreFoundation 0x000000010e15f2fc __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12
47 CoreFoundation 0x000000010e143a5b __CFRunLoopDoBlocks + 203
48 CoreFoundation 0x000000010e143254 __CFRunLoopRun + 1060
49 CoreFoundation 0x000000010e142bb9 CFRunLoopRunSpecific + 409
50 GraphicsServices 0x00000001113c49e2 GSEventRunModal + 62
51 UIKit 0x000000010e630cb2 UIApplicationMain + 159
52 WebDriverAgentRunner-Runner 0x000000010d13b835 WebDriverAgentRunner-Runner + 6197
53 libdyld.dylib 0x0000000112abfb95 start + 1
)
_rootElement should have been fixed. Do you latest WDA?
marekcirkos
on 14 Jul 2017
@mykola-mokhnach I think we will need to keep XCElementSnapshots anyway. WE need to find a way to get the tree anyway. We just might need to be smart of how we do it. I think fetching a tree wouldn't be a problem. xpath and your xpath like endpoint will be a challenge (I told you to kill it ;) ).
marekcirkos
on 14 Jul 2017
@marekcirkos Yes, it is a pain, but too many things depend on xpath search. Have you already seen my POC for updated xpath from the comment above?
mykola-mokhnach
on 14 Jul 2017
@marekcirkos And regarding class chain search it will be now even more important than ever, since it it's going to wrap native children and descendant selectors provided by XCode, which makes class chain location the fastest and most optimal method to lookup elements based on their hierarchy and/or node attributes. Unless you need something really advanced, like xpath axes. That is what the rewritten PR https://github.com/facebook/WebDriverAgent/pull/612 addresses.
mykola-mokhnach
on 14 Jul 2017
@marekcirkos Yes, this morning's updates work now! It kind of broke lower iOS support, but I've submitted a PR for that.
imurchie
on 14 Jul 2017
Predicate search raises SIGABRT in iOS11 if one tries to execute predicate search where variable name equals to FBElement member name instead of XCUIElementAttributes member name (for example wdLabel instead of label). Possible solution would be to format predicate expressions differently for iOS11, so they map wd-like names to XCUIElementAttributes member names. @marekcirkos do you have any other ideas?
mykola-mokhnach
on 14 Jul 2017
Some more knowledge sharing about how the stuff works now in iOS 11: the actual content of element attributes is now resolved during search query execution at runtime. This means, that by executing descendants lookup by type ANY these descendants will be returned with all their properties set to default values unless one reads the corresponding XCUIElement's property from _XCUIElementAttributes_ protocol to "fill" the necessary fields. XCTest only keep pointers to the located elements and will lazily resolve the corresponding attribute values upon their invocation.
For XML tree building this means we not only need to gather all descendants, but also read the corresponding XCUIElement (and not XCElementSnapshot) attributes at least once (however each XCUIElementAttributes's property call is not cached and invokes a new internal XCTest request).
mykola-mokhnach
on 14 Jul 2017
keyboard type text in not working for ios 11 using xcode 9
ketan077
on 17 Jul 2017
@marekcirkos when you said we might need to drop snapshots, I'm suspecting its because as of Xcode 9 the internal implementation for snapshots has changed? (i.e. frame on snapshot comes back as Inf. or non existent).
rafe-g
on 18 Jul 2017
@rafael-chavez Yeah, This happens often, because snapshots are out-dated. We can resolve them more often and trick into old behaviour, but I am afraid it would be temporary solution. So we are looking into different solution.
marekcirkos
on 18 Jul 2017
keyboard is not working for ios 11 using Xcode 9 beta 2 issue. below is the log
t = 32.60s Find the Application "com.apple.mobilesafari" 0x1c40b49a0
t = 32.60s Snapshot accessibility hierarchy for app with pid 299
t = 33.08s Snapshot accessibility hierarchy for app with pid 299
t = 33.66s Find: Descendants matching type Keyboard
t = 33.77s Find the Keyboard
t = 33.77s Snapshot accessibility hierarchy for app with pid 299
t = 34.20s Find: Descendants matching type Keyboard
t = 34.21s Snapshot accessibility hierarchy for app with pid 299
t = 34.61s Find: Descendants matching type Keyboard
t = 34.62s Snapshot accessibility hierarchy for app with pid 299
t = 34.96s Find: Descendants matching type Keyboard
t = 35.07s Find the Keyboard
t = 35.07s Snapshot accessibility hierarchy for app with pid 299
t = 35.47s Find: Descendants matching type Keyboard
t = 35.48s Snapshot accessibility hierarchy for app with pid 299
t = 35.84s Find: Descendants matching type Keyboard
t = 35.85s Snapshot accessibility hierarchy for app with pid 299
t = 36.19s Find: Descendants matching type Keyboard
t = 36.30s Find the Keyboard
t = 36.30s Snapshot accessibility hierarchy for app with pid 299
t = 36.65s Find: Descendants matching type Keyboard
t = 36.66s Snapshot accessibility hierarchy for app with pid 299
t = 37.02s Find: Descendants matching type Keyboard
t = 37.02s Snapshot accessibility hierarchy for app with pid 299
t = 37.35s Find: Descendants matching type Keyboard
t = 37.49s Find the Keyboard
t = 37.49s Snapshot accessibility hierarchy for app with pid 299
t = 37.80s Find: Descendants matching type Keyboard
t = 37.81s Snapshot accessibility hierarchy for app with pid 299
t = 38.16s Find: Descendants matching type Keyboard
t = 38.17s Snapshot accessibility hierarchy for app with pid 299
t = 38.49s Find: Descendants matching type Keyboard
t = 38.60s Find the Keyboard
t = 38.60s Snapshot accessibility hierarchy for app with pid 299
t = 38.98s Find: Descendants matching type Keyboard
t = 38.99s Snapshot accessibility hierarchy for app with pid 299
t = 39.45s Find: Descendants matching type Keyboard
t = 39.46s Snapshot accessibility hierarchy for app with pid 299
t = 39.87s Find: Descendants matching type Keyboard
t = 39.98s Find the Keyboard
t = 39.98s Snapshot accessibility hierarchy for app with pid 299
t = 40.37s Find: Descendants matching type Keyboard
t = 40.38s Snapshot accessibility hierarchy for app with pid 299
t = 40.77s Find: Descendants matching type Keyboard
t = 40.77s Snapshot accessibility hierarchy for app with pid 299
t = 41.21s Find: Descendants matching type Keyboard
t = 41.31s Find the Keyboard
t = 41.32s Snapshot accessibility hierarchy for app with pid 299
t = 41.70s Find: Descendants matching type Keyboard
t = 41.71s Snapshot accessibility hierarchy for app with pid 299
t = 42.09s Find: Descendants matching type Keyboard
t = 42.10s Snapshot accessibility hierarchy for app with pid 299
t = 42.52s Find: Descendants matching type Keyboard
t = 42.63s Find the Keyboard
t = 42.64s Snapshot accessibility hierarchy for app with pid 299
t = 43.01s Find: Descendants matching type Keyboard
t = 43.02s Snapshot accessibility hierarchy for app with pid 299
t = 43.41s Find: Descendants matching type Keyboard
t = 43.42s Snapshot accessibility hierarchy for app with pid 299
t = 43.82s Find: Descendants matching type Keyboard
ketan077
on 18 Jul 2017
I landed few changes that, made XCTest on Xcode 9.x behave as one on Xcode 8.x. That means everything works as usual, which is good. However it also means no, sexy benefits from Apple's sexy improvements. Tho we have bought some time to migrate it out of snapshots when Apple will release final version.
We still got few integrations tests failing, as listed on top post, but this is mainly due to verifications issues, everything works, so far ;)
marekcirkos
on 24 Jul 2017
Is there any progress being made on the XCUIDeviceRotation item?
jbruckne
on 16 Aug 2017
XCUIDeviceRotationTests - Rotation works, but orientation property is not being updated,
Perhaps it works with XCUIApplication.interfaceOrientation rather than UIDevice.orientation.
sohgoh
on 23 Aug 2017
Anyone having issues with xpath following-sibiling with Xcode 9 and Appium 1.7?
ElianaFerioli
on 26 Sep 2017
I cannot run Protractor tests on Appium, getting this error:
E/launcher - An unknown server-side error occurred while processing the command. Original error: Xcode version 9.0 is not yet supported
My capabilities are as follows:
capabilities: {

browserName: 'safari',

platformName: 'iOS',

platformVersion: '11.0',

deviceName: 'iPad Air 2',

automationName: 'XCUITest'

},
Is Xcode 9.0 really not supported?
vhopkinsff
on 29 Sep 2017
@vhopkinsff This is not an issue with WebDriverAgent.
Most likely you are running Appium 1.6.5 or lower. You will need 1.7.0 or above (preferably 1.7.1).
imurchie
on 29 Sep 2017
Hi guys! I have a huge problem with xCode 9 - unable to tap on some buttons by accessibility id. Neither of the following works
find_element(:name,'some_name').click
Appium::TouchAction.new.tap(h).perform #where h is ind_element(:name,'some_name').location.to_h
The thing is that appium can find the element in the accessibility layer, but tap takes no affect. After some investigation I realised that appium (1.7.0) incorrectly retrieves coordinates of such elements.
Has this thing already been reported? And if not- what do I do. Note that I have a landscape orientation. Pretty sure the problem is with Xcode 9 support, because rolling back to 8.3.3 fixed the problem for me
clergyman
on 2 Oct 2017
I am running Appium 1.7.0
On Fri, Sep 29, 2017 at 4:04 PM, Isaac A. Murchie notifications@github.com
wrote:
@vhopkinsff https://github.com/vhopkinsff This is not an issue with
WebDriverAgent.Most likely you are running Appium 1.6.5 or lower. You will need 1.7.0 or
above (preferably 1.7.1).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/WebDriverAgent/issues/639#issuecomment-333225496,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALlAbfADJ3r4CZziNV9uKcKlRjItAxPTks5snU0_gaJpZM4OSoIz
.
vhopkinsff
on 2 Oct 2017
Actually when I run webdriver-manager start is does say Welcome to Appium v1.6.0! How do I update it to v1.7.0 or later? Locally I have it updated, but I guess there's a second instance of Appium on the Selennium server?
vhopkinsff
on 2 Oct 2017
@vhopkinsff did you install appium via npm? If yes, did you use the '-g' flag or sudo?
There is no kind of second instance of appium on selenium (afaik), but if you didn't use the '-g' flag at the installation, appium was installed to another directory then without that flag. Maybe that leads to the fact that you have two instances of Appium installed
But this is not an WebDriverAgent issue, you should ask at Appium!
derunewige
on 5 Oct 2017
@marekcirkos @imurchie
Any Update on
1.Appium 1.7.1 Performance issue
- findelementby Xpath is too slow.
I am usinhg Xcode 9
Please let me know
stephenws
on 23 Oct 2017
@stephenws Try Appium 1.7.2@beta. xpath location should be faster there, although I would advice to not use this locator type at all.
mykola-mokhnach
on 23 Oct 2017
@mykola-mokhnach Same issue in Appium 1.7.2@beta as well, especially in larger devices like iPad Air2 or iPad Pro
swapanchhabra
on 23 Oct 2017
@marekcirkos Is it a known issue that we cant make apple provided UI (such as CNContactPickerViewController) accessible to WDA? Even after setting the view of the contact picker as accessible and giving it an accessibilityIdentifier?
rafe-g
on 24 Oct 2017
Regarding the performance issue, I did some measurements to find out why /source calls got so must slower and it seems that most of the time is spent when reading element attributes. However, it also looks like that fetching element attributes is fast for ~5 ui elements and then it gets much slower.
Measurement when reading attributes for XCUIElementTypeApplication:
First /source call:
element.wdType=0.005544 sec
element.wdValue=0.004531 sec
element.wdName=0.008188 sec
element.wdLabel=0.000006 sec
element.wdEnabled=0.00004 sec
element.wdRect=0.005228 sec
TOTAL=0.023 sec
Second /source call:
element.wdType=0.12488 sec
element.wdValue=0.103321 sec
element.wdName=0.22084 sec
element.wdLabel=0.00002 sec
element.wdEnabled=0.00008 sec
element.wdRect=0.11783 sec
TOTAL=0.55 sec
Interestingly, after ~5 ui elements it seems that fetching attributes for every other ui element needs 0.55-0.6 sec (tested on iPad Pro, iOS 11.0.3, Xcode 9.0.1). Without knowing it better, I believe that XCTest sends some kind of message back to the Mac whenever a single element attribute is read and this message queue gets full after some time which then stalls the whole test execution. Maybe this helps someone with more knowledge about this.
cschabetsberger-micro-focus
on 25 Oct 2017
Thanks for the numbers @cschabetsberger-micro-focus
Could you please try to insert these three lines at the beginning of the XCUIElement+FBUtilities.m->fb_lastSnapshot method:
if (self.lastSnapshot) {
return self.lastSnapshot;
}
Then recompile WDA and try again?
mykola-mokhnach
on 25 Oct 2017
I'm getting an error with a newly-compiled version of WDA (the one from appium 1.7.2-beta) on Xcode9 running on an iphone 6 with iOS 10. Whenever I do a GET request to the /source?format=xml page, I receive an error indicating a syntax error in the XCUIElement+FBUtilities.h file, has anyone else seen anything like ths:
-[XCElementSnapshot fb_hitPoint]: unrecognized selector sent to instance 0x153bf7190
(
0 CoreFoundation 0x000000018348aff8 <redacted> + 148
1 libobjc.A.dylib 0x0000000181eec538 objc_exception_throw + 56
2 CoreFoundation 0x0000000183491ef4 <redacted> + 0
3 CoreFoundation 0x000000018348ef54 <redacted> + 916
4 CoreFoundation 0x000000018338ad4c _CF_forwarding_prep_0 + 92
5 WebDriverAgentLib 0x00000001022599b4 -[XCElementSnapshot(FBIsVisible) fb_isVisible] + 520
6 WebDriverAgentLib 0x00000001022668b0 -[XCElementSnapshot(WebDriverAttributes) isWDVisible] + 40
7 WebDriverAgentLib 0x00000001022520ac -[FBVisibleAttribute value] + 60
8 WebDriverAgentLib 0x000000010225183c -[FBElementAttribute recordWithWriter:] + 44
9 WebDriverAgentLib 0x0000000102250df4 +[FBXPath recordElementAttributes:forElement:indexPath:includedAttributes:] + 512
10 WebDriverAgentLib 0x00000001022512b0 +[FBXPath generateXMLPresentation:indexPath:elementStore:includedAttributes:writer:] + 796
11 WebDriverAgentLib 0x0000000102250668 +[FBXPath getSnapshotAsXML:writer:elementStore:query:] + 452
12 WebDriverAgentLib 0x000000010224fa58 +[FBXPath xmlStringWithSnapshot:] + 112
13 WebDriverAgentLib 0x00000001022677cc +[FBDebugCommands handleGetSourceCommand:] + 592
14 WebDriverAgentLib 0x000000010225bc9c -[FBRoute_TargetAction mountRequest:intoResponse:] + 208
15 WebDriverAgentLib 0x00000001022538d4 __37-[FBWebServer registerRouteHandlers:]_block_invoke + 496
16 RoutingHTTPServer 0x00000001023063cc -[RoutingHTTPServer handleRoute:withRequest:response:] + 144
17 RoutingHTTPServer 0x0000000102306b80 __72-[RoutingHTTPServer routeMethod:withPath:parameters:request:connection:]_block_invoke + 44
18 libdispatch.dylib 0x00000001823429a0 <redacted> + 16
19 libdispatch.dylib 0x00000001823537a8 <redacted> + 304
20 libdispatch.dylib 0x00000001823429a0 <redacted> + 16
21 libdispatch.dylib 0x00000001823475e8 _dispatch_main_queue_callback_4CF + 996
22 CoreFoundation 0x00000001834390c8 <redacted> + 12
23 CoreFoundation 0x0000000183436ce4 <redacted> + 1572
24 CoreFoundation 0x0000000183366da4 CFRunLoopRunSpecific + 424
25 Foundation 0x0000000183e81db4 <redacted> + 304
26 WebDriverAgentLib 0x00000001022528fc -[FBWebServer startServing] + 424
27 WebDriverAgentRunner 0x000000010223fbe4 -[UITestingUITests testRunner] + 132
28 CoreFoundation 0x0000000183490e80 <redacted> + 144
29 CoreFoundation 0x00000001833862c4 <redacted> + 292
30 XCTest 0x00000001001d40a8 __24-[XCTestCase invokeTest]_block_invoke.275 + 48
31 XCTest 0x0000000100220f08 -[XCTMemoryChecker _assertInvalidObjectsDeallocatedAfterScope:] + 56
32 XCTest 0x00000001001d3e58 __24-[XCTestCase invokeTest]_block_invoke + 680
33 XCTest 0x0000000100219780 -[XCUITestContext performInScope:] + 208
34 XCTest 0x00000001001d3ba0 -[XCTestCase invokeTest] + 136
35 XCTest 0x00000001001d4c78 __26-[XCTestCase performTest:]_block_invoke.382 + 48
36 XCTest 0x000000010021e778 +[XCTContext runInContextForTestCase:block:] + 164
37 XCTest 0x00000001001d4674 -[XCTestCase performTest:] + 596
38 XCTest 0x00000001001d0868 __27-[XCTestSuite performTest:]_block_invoke + 288
39 XCTest 0x00000001001d0290 -[XCTestSuite _performProtectedSectionForTest:testSection:] + 44
40 XCTest 0x00000001001d04a0 -[XCTestSuite performTest:] + 236
41 XCTest 0x00000001001d0868 __27-[XCTestSuite performTest:]_block_invoke + 288
42 XCTest 0x00000001001d0290 -[XCTestSuite _performProtectedSectionForTest:testSection:] + 44
43 XCTest 0x00000001001d04a0 -[XCTestSuite performTest:] + 236
44 XCTest 0x00000001001d0868 __27-[XCTestSuite performTest:]_block_invoke + 288
45 XCTest 0x00000001001d0290 -[XCTestSuite _performProtectedSectionForTest:testSection:] + 44
46 XCTest 0x00000001001d04a0 -[XCTestSuite performTest:] + 236
47 XCTest 0x0000000100227f5c __44-[XCTTestRunSession runTestsAndReturnError:]_block_invoke + 44
48 XCTest 0x00000001001e33e8 -[XCTestObservationCenter _observeTestExecutionForBlock:] + 420
49 XCTest 0x0000000100227dd8 -[XCTTestRunSession runTestsAndReturnError:] + 292
50 XCTest 0x00000001001bfed0 -[XCTestDriver runTestsAndReturnError:] + 312
51 XCTest 0x000000010021d920 _XCTestMain + 620
52 CoreFoundation 0x000000018343930c <redacted> + 20
53 CoreFoundation 0x0000000183438b28 <redacted> + 288
54 CoreFoundation 0x0000000183436998 <redacted> + 728
55 CoreFoundation 0x0000000183366da4 CFRunLoopRunSpecific + 424
56 GraphicsServices 0x0000000184dd1074 GSEventRunModal + 100
57 UIKit 0x0000000189621c9c UIApplicationMain + 208
58 WebDriverAgentRunner-Runner 0x0000000100048430 WebDriverAgentRunner-Runner + 33840
59 libdyld.dylib 0x000000018237559c <redacted> + 4
)
aristeia
on 26 Oct 2017
Can you guys, who have problems with slow /source, try to patch your local WDA with the patch from https://github.com/facebook/WebDriverAgent/pull/764 PR and, if that does not work, comment out
rc = xmlTextWriterWriteAttribute(writer, BAD_CAST "visible", element.wdVisible ? BAD_CAST "true" : BAD_CAST "false");
if (rc < 0) {
[FBLogger logFmt:@"Failed to invoke libxml2>xmlTextWriterWriteAttribute(wdVisible). Error code: %d", rc];
return rc;
}
lines in FBXPath.m?
mykola-mokhnach
on 26 Oct 2017
Thank you @mykola-mokhnach for the tip to re-use the lastSnapshot but unfortunately this only seems to have minor influence on this. My iPad Pro needs now 28-29 sec to fetch the whole hierarchy in my test app (and still 0.6 sec for a single element) - before the change it needed 30 - 31 sec.
I commented out the wdVisible check also in my original measurement because that had other issues in the past which I wanted to rule out.
cschabetsberger-micro-focus
on 27 Oct 2017
@cschabetsberger-micro-focus
I have one more guess, which worth checking.
Insert the
[application fb_descendantsMatchingPredicate:[FBPredicate predicateWithFormat:@"1 == 1"] shouldReturnAfterFirstMatch:NO];
line into FBDebugCooamnds.m before the
result = [FBXPath xmlStringWithSnapshot:application.fb_lastSnapshot];
Do not forget to additionally import :
#import "FBPredicate.h"
#import "XCUIElement+FBFind.h"
According to my idea this should force internal resolving of snapshot attributes and speed up the further values reading.
mykola-mokhnach
on 27 Oct 2017
@mykola-mokhnach thank you for this suggestions but unfortunately this does not seem to have any effect on the execution time. I will do some more testing and try to narrow the issue further down.
cschabetsberger-micro-focus
on 27 Oct 2017
One thing I would like to try is to specify a custom XCTestConfiguration for the xcodebuild process and set "reportActivities:no" and "reportResultsToIDE:no", but so far I have not found a way how to specify such a configuration file for the xcodebuild process. Does anybody know how that works?
cschabetsberger-micro-focus
on 27 Oct 2017
@cschabetsberger-micro-focus I've polished my hack a bit and now the patch looks like
--- FBDebugCommands.m 2017-10-27 09:23:14.000000000 +0200
+++ /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgentLib/Commands/FBDebugCommands.m 2017-10-29 21:12:00.000000000 +0100
@@ -15,6 +15,9 @@
#import "XCUIApplication+FBHelpers.h"
#import "XCUIElement+FBUtilities.h"
#import "FBXPath.h"
+#import "XCUIElement.h"
+#import "XCUIElement+FBWebDriverAttributes.h"
+#import "XCUIElement+FBFind.h"
@implementation FBDebugCommands
@@ -41,7 +44,8 @@
id result;
if (!sourceType || [sourceType caseInsensitiveCompare:@"xml"] == NSOrderedSame) {
[application fb_waitUntilSnapshotIsStable];
- result = [FBXPath xmlStringWithSnapshot:application.fb_lastSnapshot];
+ XCUIElement *targetElement = [application fb_descendantsMatchingPredicate:[NSPredicate predicateWithFormat:@"wdUID == %@", @(application.wdUID)] shouldReturnAfterFirstMatch:NO].firstObject;
+ result = [FBXPath xmlStringWithSnapshot:targetElement.lastSnapshot];
} else if ([sourceType caseInsensitiveCompare:@"json"] == NSOrderedSame) {
result = application.fb_tree;
} else {
I tested it on my app and got ~2x performance improvement. Please let me know if it works for you.
mykola-mokhnach
on 29 Oct 2017
@mykola-mokhnach thank you for the update. I tried this on my iPad Pro but untfortunately I did not notice any difference. A single /source call still takes ~28 sec. I ran the same test also on my iPhone 5s just for comparison and the /source call took around 3.5 sec. So there must be something which slows down the XCTest execution especially on iPads. However, when I ran a /source command with Xcode 8 and iOS 10 on my iPhone 5s, it took around 200ms.
cschabetsberger-micro-focus
on 30 Oct 2017
Yes, problem is with bigger devices. Execution on iPads are really slow. A test suite that take around 4.5 hours to complete on iPhone 7, is taking 12 hours to execute on iPad Air2. Please suggest solution for it.
swapanchhabra
on 31 Oct 2017
Hi, I have a WDA connection time out issue whenever I try to click on an alert in a big table view.
When there are too many elements in the table, finding element in the table works fine, but I have a condition that click on the item will pops up an alert, at this point, WDA cannot response to the alert and giving some connection time out error.
Some logs are as follow, appreciate if anyone can help, blocking a lot of test cases.
Calling AppiumDriver.postAcceptAlert() with args: ["1c4c97ff-33a1-4939-a2bd-06ce03c7220f"]
[debug] [XCUITest] Executing command 'postAcceptAlert'
[debug] [JSONWP Proxy] Proxying [POST /alert/accept] to [POST http://localhost:8100/session/383383E4-FF65-4A7A-925F-6FF8F43E1DA0/alert/accept] with body: {}
[debug] [XCUITest] Log file for xcodebuild test: /var/folders/9d/p_pzdlmd5531hxnvz1n106y40000gn/T/com.apple.dt.XCTest/IDETestRunSession-741F7B55-0A0A-4DA5-813A-9256C9311930/WebDriverAgentRunner-454926DF-F1BD-41E8-8989-EC6DF8D04EDA/Session-WebDriverAgentRunner-2017-10-31_150852-P5yl7C.log
[debug] [XCUITest] Connection to WDA timed out
[debug] [iProxy] recv failed: Operation not permitted
[MJSONWP] Encountered internal error running command: ProxyRequestError: Could not proxy command to remote server. Original error: Error: socket hang up
at JWProxy.proxy$ (../../../lib/jsonwp-proxy/proxy.js:152: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:100:21)
at GeneratorFunctionPrototype.invoke (/usr/local/lib/node_modules/appium/node_modules/babel-runtime/regenerator/runtime.js:136:37)
zixincheng
on 31 Oct 2017
There is now one more source format type available, which is based on the native XCTest output: source?format=description. The example output there looks like
Attributes: Window, 0x60000039ac30, {{0.0, 0.0}, {375.0, 667.0}}, identifier: 'ZClientMainWindow'
Element subtree:
→Window, 0x60000039ac30, {{0.0, 0.0}, {375.0, 667.0}}, identifier: 'ZClientMainWindow'
Other, 0x60000039b2b0, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039b1e0, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039b110, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039b040, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039af70, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039aea0, traits: 8589934592, {{-100.0, 0.0}, {575.0, 667.0}}
Image, 0x60000039add0, traits: 8589934596, {{-215.0, -133.4}, {805.0, 933.8}}
Other, 0x60000039ad00, traits: 8589934592, {{-215.0, -133.4}, {805.0, 933.8}}
Other, 0x60000039aa90, traits: 8589934592, {{-215.0, -133.4}, {805.0, 933.8}}
Other, 0x60000039a750, traits: 8589934592, {{-215.0, -133.4}, {805.0, 933.8}}
Other, 0x60000039a820, traits: 8589934592, {{0.0, 0.0}, {375.0, 667.0}}
Other, 0x60000039a680, traits: 8589934592, {{0.0, 20.0}, {375.0, 647.0}}
Other, 0x60000039a5b0, traits: 8589934592, {{0.0, 20.0}, {375.0, 44.0}}
Button, 0x60000039a410, traits: 8589934593, {{9.0, 19.0}, {46.0, 46.0}}, identifier: 'bottomBarSettingsButton', label: 'Profile', value: 0y6jqp3z account. ...
and might be useful for internal debugging purposes, since the performance of this call is simply outstanding in comparison to the xml one.
mykola-mokhnach
on 7 Nov 2017
If source?format=description is so much faster, why not take that output and convert it to XML internally in WDA?
rsveldema
on 8 Nov 2017
Ps, a measurement with format=description vs format=xml:
description took: 490 millis
xml took: 25808 millis
rsveldema
on 16 Nov 2017
@rsveldema Can you please let us know How you used description format instead of xml? or in which files do we need to configure this?
swapanchhabra
on 17 Nov 2017
Unfortunately, many places needed patching to get our java based tests to use this:
- Appium server
- selenium-java
- java-client (of Appium)
- our java based tests
In short:
I added a new function IOSDriver.getNativePageSource() in java-client which calls RemoteWebDriver.getNativePageSource() in selenium-java. That in turn creates a URI with source?format=description which is parsed by Appium-server. That routing/parsing code needed a patch to work and that in turn calls the latest WDA's /source?format=description.
Unfortunately, I wrote this for a client so I can't yet release the source for the patches but the above should get you started if you want to reproduce this.
rsveldema
on 17 Nov 2017
Dear sirs, I've tried with 1.7.2 beta but still no luck with clicking on element ID
find_element(:name,'some_name').click
Appium::TouchAction.new.tap(h).perform #where h is ind_element(:name,'some_name').location.to_h
- neither of these works
Are there any similar resorts? I can click on some buttons and cannot click on other. This is crap because it's basic functionality and it's broken. It is surely related with xcode version because I can fix the problem by rolling back to xcode 8, however, the tested application is no longer compatible with it.
clergyman
on 29 Nov 2017
@clergyman I think your issues linked this thread #798
you should see it.
kycho
on 1 Dec 2017
Any progress on getPageSource() with iOS 11 on iPhone / iPad? getPageSource() takes an extremely long time to complete and my Appium tests time out. I'm using XCUITest and Appium-Desktop 1.2.7 (running Appium-Server 1.7.1) to test a Native application.
jaredgilmore
on 6 Dec 2017
@jaredgilmore - Exact same issue here. My test scripts won't work at all and I've been holding off on rewriting them to get around this b/c I had started using getPageSource() to validate that elements were visible / enabled by parsing the source into JSON. Using driver.findElementBy for each element I needed to validate was taking too long but at least the tests completed. This has been going on far too long.
VTINFOJames
on 7 Dec 2017
I'm using getPageSource() for UI Performance test. now it is nightmare for iOS 11. it costs 9min to continuous getPageSource() for 100 cycles. Could you make it faster? I really appreciate if it can be faster as for iOS10.3
wendyyy
on 8 Dec 2017
Since Apple closed ios 10.3.3, all new ios devices are started at 11.x.
I just test xcode 9.2 vs ios 11.2. it's not productive for automation testing (like slow pagesource).
We hope that there were some short workarounds to at least make it testing run on these platform.
BRs,
xygwfxu
on 12 Dec 2017
- Workaround for slow pagesource : As we were using xpaths as locators in our framework and whole test suite was taking around 12-13 hours, but now after replacing most of locators to accessibility ids, It is now taking 5 hours to complete.
The main reason behind same would be that when we use xpaths, it fetch page source but if we use IDs it only fetch id's from xml.
Even in any application automation we cannot replace use of xpaths but we should use xpaths as less as possible.
swapanchhabra
on 12 Dec 2017
@wendyyy @swachhab @jaredgilmore #804 improves XML performance by 30% which was merged this morning which may help.
chendo
on 12 Dec 2017
So I just need to do changes in "WebDriverAgentLib/Utilities/FBXPath.m"? as per "https://github.com/facebook/WebDriverAgent/pull/804/files/e7c29534a53373f70a97a8cac3dcad650022c60b"
swapanchhabra
on 12 Dec 2017
@chendo : Thanks a lot, even it improved performance upto 50%, COOL!
swapanchhabra
on 12 Dec 2017
Hi @chendo @swachhab , How should I use #804? I still met bad performance issue. Below is my steps, are there any incorrect?
I fetch the latest code: commit 1e3b14a641624f568be66ed33f861c5ad18850d8 master
And execute: ./Scripts/bootstrap.sh
And then replace /Applications/Appium1.2.7.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent with WebDriverAgent
I cleaned all WebDriverAgent folder under ~/Library/Developer/Xcode/DerivedData
Launch Appium1.2.7, and test, Here's the log:
[info] [XCUITest] Using WDA path: '/Applications/Appium1.2.7.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent'
[info] [XCUITest] Using WDA agent: '/Applications/Appium1.2.7.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj'
[debug] [XCUITest] Capability 'useNewWDA' set to true, so uninstalling WDA before proceeding
[info] [XCUITest] Shutting down sub-processes
[debug] [XCUITest] Removing WDA application from device[debug] [XCUITest] Log file for xcodebuild test: /var/folders/nq/v4xpf51j62qdv9pjxj819f_8pzclps/T/com.apple.dt.XCTest/IDETestRunSession-6D9D536C-AB8C-46CD-94FA-5B721994978E/WebDriverAgentRunner-88DE303B-27A6-4D69-9186-FE42A548AD8E/Session-WebDriverAgentRunner-2017-12-12_175055-SYiZxW.log[debug] [BaseDriver] Event 'wdaUninstalled' logged at 1513072256115 (17:50:56 GMT+0800 (CST))
[debug] [BaseDriver] Event 'wdaStartAttempted' logged at 1513072256117 (17:50:56 GMT+0800 (CST))
[info] [XCUITest] Launching WebDriverAgent on the device
[debug] [XCUITest] Carthage found: '/usr/local/bin/carthage'
[debug] [XCUITest] Killing running processes 'xcodebuild.2B4CEFFE-F2B5-45DD-B411-EB4B04789B22, iproxy 8100, 2B4CEFFE-F2B5-45DD-B411-EB4B04789B22.XCTRunner' for the device 2B4CEFFE-F2B5-45DD-B411-EB4B04789B22...
[info] [XCUITest] xcodebuild exited with code 'null' and signal 'SIGINT'[debug] [XCUITest] 'pgrep -nif xcodebuild.2B4CEFFE-F2B5-45DD-B411-EB4B04789B22' didn't detect any matching processes. Return code: 1
[debug] [XCUITest] 'pgrep -nif iproxy 8100' didn't detect any matching processes. Return code: 1
[debug] [XCUITest] 'pgrep -nif 2B4CEFFE-F2B5-45DD-B411-EB4B04789B22.XCTRunner' didn't detect any matching processes. Return code: 1
[debug] [XCUITest] Using Xcode 9.0, so fixing WDA codebase
[debug] [XCUITest] Beginning test with command 'xcodebuild build-for-testing test-without-building -project /Applications/Appium1.2.7.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id=2B4CEFFE-F2B5-45DD-B411-EB4B04789B22 IPHONEOS_DEPLOYMENT_TARGET=11.0' in directory '/Applications/Appium1.2.7.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent'
[debug] [XCUITest] Output from xcodebuild will not be logged. To see xcode logging, use 'showXcodeLog' desired capability[debug] [XCUITest] Waiting up to 60000ms for WebDriverAgent to start
[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [XCUITest] Log file for xcodebuild test: /var/folders/nq/v4xpf51j62qdv9pjxj819f_8pzclps/T/com.apple.dt.XCTest/IDETestRunSession-704A6159-ED5F-41FD-9E3E-7FADB825A29C/WebDriverAgentRunner-73202D36-FF8D-4E11-A5AB-47ADF903A788/Session-WebDriverAgentRunner-2017-12-12_175109-E0YMOd.log[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body[debug] [JSONWP Proxy] Proxying [GET /status] to [GET http://localhost:8100/status] with no body
[debug] [JSONWP Proxy] Got response with status 200: "{\n \"value\" : {\n \"state\" : \"success\",\n \"os\" : {\n \"name\" : \"iOS\",\n \"version\" : \"11.0\"\n },\n \"ios\" : {\n \"simulatorVersion\" : \"11.0\",\n \"ip\" : \"10.58.100.200\"\n },\n \"build\" : {\n \"time\" : \"Dec 12 2017 17:51:01\"\n }\n },\n \"sessionId\" : \"F88046F0-7EAB-4D7C-AD62-F37436D8590A\",\n \"status\" : 0\n}"
[debug] [XCUITest] WebDriverAgent running on ip
wendyyy
on 12 Dec 2017
Yes, All those steps are correct, It should work
swapanchhabra
on 12 Dec 2017
I pulled the WebDriverAgent project #804, replaced my existing WebDriverAgent folder in the Appium-Desktop app with the new version, in Terminal I navigated to the WebDriverAgent folder (Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent) and ran the command ./Scripts/bootstrap.sh to pull in dependencies, then opened the WebDriverAgent project in the WebDriverAgent folder, signed the WebDriverAgent components in Xcode and built them to the device (IntegrationApp, WebDriverAgentRunner, WebDriverAgentLib). getPageSource() is still very slow however, it works. The native app I am testing is very robust with many screens layered upon another; each with 1 to 100's of elements. So the slowness may be less of a problem on a less-complex iOS application. I am running Xcode 9.2, iOS 11.2, and Appium-Desktop version 1.2.7.
VTINFOJames
on 29 Dec 2017
Hi all, are there any updates on this topic? Because iPad speed is still dramatically slow as described here https://github.com/appium/appium/issues/9985.
senevit4
on 17 Jan 2018
@marekcirkos I have made some progress on speeding up the getSource command here #838
tmulkern
on 22 Jan 2018
I am trying to use forcePressAtPoint function. It works OK on iOS 10.3 with Xcode9.2, but on iOS 11 it doesn't work properly. Sometimes the quick launch menu is opened sometimes is not opened. When is opened, the quick action buttons are not working.
danubiusdan
on 27 Feb 2018
Python is throwing BadStatusLine errors when conducting long tests in iOS 11.2.5.
auto-mator
on 28 Feb 2018
Hi All,
Just would like to find out when will it start to support for WEBVIEW heavy applications (Iconic / Phonegap) build against XCode 9.2? Thanks
laxmikantm
on 8 Mar 2018
I am using Appium 1.7.1 and XCode 9.2. I am running into extremely slow execution of test on pages with tabular UI, though there are just about 7-8 rows in the table. The log shows that the execution is stuck at this step.
[debug] [MJSONWP] Calling AppiumDriver.findElement() with args: ["xpath",".//*[contains(@name, 'Sign out')]","ed10a69d-7601-4081-ab3e-2b086d8cac92"]
[debug] [XCUITest] Executing command 'findElement'
[debug] [BaseDriver] Valid locator strategies for this request: xpath, id, name, class name, -ios predicate string, -ios class chain, accessibility id
[debug] [BaseDriver] Waiting up to 10000 ms for condition
[debug] [JSONWP Proxy] Proxying [POST /element] to [POST http://localhost:8100/session/EA5A311C-1CB5-4C07-B13E-D663DB48EB66/element] with body: {"using":"xpath","value":".//*[contains(@name, 'Sign out')]"}
[HTTP] <-- POST /wd/hub/session/ed10a69d-7601-4081-ab3e-2b086d8cac92/element - - ms - -
[HTTP] --> POST /wd/hub/session/ed10a69d-7601-4081-ab3e-2b086d8cac92/element {"using":"xpath","value":".//*[contains(@name, 'Sign out')]"}
[debug] [MJSONWP] Calling AppiumDriver.findElement() with args: ["xpath",".//*[contains(@name, 'Sign out')]","ed10a69d-7601-4081-ab3e-2b086d8cac92"]
[debug] [XCUITest] Executing command 'findElement'
Unfortunately, I can't use an accessibility ID for this locator and it has to be XPath. Though the execution is really slow with XPath, it does proceed in other few cases where I use XPath, but it just gets frozen here and the test eventually fails with the error below after a few minutes.
[Xcode] 2018-03-22 15:19:24.736846-0700 WebDriverAgentRunner-Runner[251:5089] Enqueue Failure: Failure fetching attributes for element <XCAccessibilityElement: 0x1c1a60400> pid: 255, elementOrHash.elementID: 4410879072.14: Error Domain=XCTDaemonErrorDomain Code=13 "Error copying attributes -25216" UserInfo={NSLocalizedDescription=Error copying attributes -25216} /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgentRunner/UITestingUITests.m 37 1
[Xcode] 2018-03-22 15:20:24.745627-0700 WebDriverAgentRunner-Runner[251:5089] Enqueue Failure: Failure fetching attributes for element <XCAccessibilityElement: 0x1c1462ec0> pid: 255, elementOrHash.elementID: 4410832640.54: Error Domain=XCTDaemonErrorDomain Code=13 "Error copying attributes -25216" UserInfo={NSLocalizedDescription=Error copying attributes -25216} /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/WebDriverAgentRunner/UITestingUITests.m 37 1
Is there a resolution for this in any of the appium versions? I tried 1.7.2 a while earlier, but ran into issues with the "click()" methods on some of the elements in my app's UI. Please unblock me on this.
shabsi4u
on 22 Mar 2018
Any progress on this old bug/comment:
"There also seems to be a 3-5 second pause while clicking on any element. I don't have any logs or anything from that, since it doesn't produce any... just sits there and then successfully clicks."
Which is probably caused by " my bet is on the fact that element queries are now executed on application side, not XCTest"?
This bug is plaguing my tests, and the workarounds I'm employing arent enough to enable me to accurately time how long a clicked link takes to load.
aristeia
on 27 Mar 2018
ping, can we get an update please? The clicks are the only one blocking me from adopting 1.7.2. Has any work been done on this front?
shabsi4u
on 16 Apr 2018
Also on Appium 8.0 and ios 11.2 XCUI test, getting errors with finding elements. This is what i can find from the log. Anybody else facing this issue, this is not 100% reproducible and if it reproduces it will be there for couple of runs/tests.
Proxying [POST /elements] to [POST http://localhost:25352/session/795337EC-42F0-47D3-9065-4ECA923E909B/elements] with body: {"using":"xpath","value":"//XCUIElementTypeTextField[1]"}
0x0000000107086fc0 -[XCUIElement(FBFind) fb_descendantsMatchingXPathQuery:shouldReturnAfterFirstMatch:] + 204\n\t8 WebDriverAgentLib 0x00000001070a4a14 +[F...
sharecommute
on 27 Apr 2018
@shabsi4u, @sharecommute xpath is know to be slow. My best advice is not to use unfrotunately. Closing task since we run fine on Xcode 9
marekcirkos
on 10 May 2018
If you are using Appium, try 1.8.1-beta (npm uninstall -g appium && npm install -g appium@beta). XML generation has been significantly improved.
imurchie
on 10 May 2018
Related issues
Terrdy
·
8Comments
monleylu
·
16Comments
MarkSunPWC
·
19Comments
pkulkarnii
·
4Comments
garie
·
10Comments
Most helpful comment
@marekcirkos I have made some progress on speeding up the getSource command here #838