-
Notifications
You must be signed in to change notification settings - Fork 370
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
Intermittent timeouts performing gestures in Xcode 6.1 targeting iOS 8.1 simulators #585
Comments
@JaniJegoroff this is great. We're working on this issue. I still would be a lot faster if I could access to an app where this reproduces, including source-code level access. Would it be possible to create a new app and create similar logic/behaviour to your app to reproduce it in a minimal context you can share? |
AFAICT, it is not possible to tell calabash not to dismiss those alerts. Please file an issue in https://github.com/calabash/run_loop/issues I am not sure yet how we will be able to distinguish these APNS alerts from other alerts. |
Unfortunately, creating a new app with similar logic is out of my skills set. :( I'm going to need help from our dev's but it will go to the next week. Meanwhile, I'm trying to find a simpler way (not involving APNS) to reproduce. |
Can you try this change in your
The :preference strategy (AKA fast UIA) uses the UIAutomation preferences API to read requests and write results. Historically it has been must faster that the alternative strategy :host. The :host strategy (AKA host/cat), uses the UIAutomation API to read requests and write results to a file on the host machine. In previous versions of Xcode, the underlying JavaScript call Both strategies were more-or-less broken during the Xcode 6 betas. The :preferences strategy stabilized for Xcode 6.0.1, but it looks like it has become unstable in Xcode 6.1 targeting iOS 8.1 Simulators when client application use NSUserDefaults. I can't, for example, reproduce this problem in Xcode 6.1 with iOS 7.1 Simulators. +1 for the bug report. |
@jmoody - Debug trace
run_loop.out
|
@jmoody - :host strategy works in my case too. Debug trace looks nearly the same, so I don't paste it. |
I am also getting timeout, not sure if this is related to this same case... Feature: Ensure Case Conversation actions Scenario: Add a note to case # features/case_conversation.feature:3 |
@axhossain Yours is an unrelated problem. #550 |
@jmoody :host strategy works in my case too. |
@jmoody with :host strategy another deterministic timeout occurs with uia.typeString. |
For those experiencing this issue could you try 0.11.4.pre1 (both client, server and run_loop updates) NOTE: this doesn't not fix issues related to push notifications and timeouts. |
Please report back here. |
I have merged Karl's fix into develop with a fix for iOS 7.1 simulators on Xcode 6.1. |
I've updated the sample app to use both location dialog and push notifications. Both are dismissed fine and the automation works. @JaniJegoroff @nfrydenholm could you help reproducing the issue by making appropriate changes to this app: https://github.com/calabash/calabash-ios-example Note since this app adds Calabash server source code you must checkout the develop branch of https://github.com/calabash/calabash-ios-server into the folder:
(relative to where calabash-ios-example project is) |
@krukow @jmoody I found a way to reproduce issue every time. Could you give a try? |
@JaniJegoroff thanks for doing the work. I was able to reproduce this consistently -- it is a race condition in UIAutomation. I will need to think about how to work around this. I have a couple of ideas. |
@JaniJegoroff -- this is probably not the final solution since it slows down handling of alert views by a second or so, but could you try this as a workaround: Use this version of run_loop (calabash/run_loop origin/workaround-preferences-write-issue) Corresponding to: Rubygems is not allowing publishing right now, but I will publish tomorrow as When that happens and you want to test this - add in your Gemfile:
|
cc: @nfrydenholm |
@krukow Cool, I will check this tomorrow. |
Pushed run_loop 1.1.1.pre3 to rubygems.org. |
@krukow Good work, I can confirm that my scenarios are passing with run_loop 1.1.1pre3 |
Sounds good --- @jmoody FYI this is probably not our final solution as it will slow down the script in certain scenarios. So please don't merge this pull request. @JaniJegoroff we will look at tweaking this solution so it avoids the slowdown but still works as expected. |
@JaniJegoroff could you try also the version of server (0.11.5.pre1) here: calabash/calabash-ios-server#97 combined with and run_loop 1.1.1.pre4 cc: @nfrydenholm |
@krukow - I executed my APNS scenario with following setup: No problems detected. |
@JaniJegoroff thanks. I'm closing this issue! |
Sorry for not being active on this one - I just got back from a nice long vacation ;) |
Background
This is a new issue for a discussion originally started in #566
Most users are experiencing intermitted timeouts but I have a push notification scenario where I can reproduce issue every time.
Environment
Xcode 6.1
Calabash 0.11.3
run_loop 1.0.9
8.1 simulators
My original use case
I was working with push notification related scenario today and came across with timeout issue as well. Issue is reproducible every time. I'm writing values to NSUserDefaults during this scenario. Scenario is about showing custom "would you like to accept push notifications" screen to the user. After user taps two buttons (Sure and Next) in notifications screen then system level push notification alert view is shown. UI flow is like below:
UI flow is completed correctly and Calabash automatically dismisses system level alert view. In spite of that tapping the "Next" button causes a timeout for some reason.
curl:
Debug trace:
run_loop.out:
Further analysis
@jmoody
I changed app implementation so that it saves notification settings to .plist instead of NSUserDefault. In spite of that I can still reproduce the issue every time.
Is there any chance that problem is related to system level alert views that Calabash is dismissing automatically? Is there way to tell Calabash NOT to dismiss those alerts views, "allow push notifications" in this case, since I would like to see behaviour when we just ignore system level alert views?
The text was updated successfully, but these errors were encountered: