Descendants Keyboard

0 views

Skip to first unread message

Salvator Grimard

unread,

Aug 3, 2024, 5:38:35 PM8/3/24

to icovfragan

I am testing adding a comment to my app, on my other UI tests I have used the typeText function and everything works perfectly fine. I have also clicked to make Connect hardware keyboard' is off. The app terminates testing and shows the error UI Testing Failure - Neither element nor any descendant has keyboard focus during the addComment method. Any ideas?

Likely cause:
An extremely common cause of this symptom is to have enabled a parent view of the field in question as an accessibility element. Ensure that none of the parents of the field are enabled as accessibility elements, and the problem is likely to be resolved.

Explanation
This error message can be particularly confusing when you can see that a previous step in the XCUITest has correctly activated a text field or similar as the first responder, the keyboard has appeared, and functionally the field has keyboard focus.

Essentially, the error message is slightly misleading as the tendency is to focus on the keyboard focus part and think that it is telling you that nothing has keyboard focus. Instead, what the message is telling you is that none of the accessibility elements that XCUITest can access have the keyboard focus. And so it can't direct text to the field in question.

Accessibility elements cannot have children that are also accessibility elements. Therefore, if you place a number of fields inside a view, but then mark that parent view as being an accessibility element, all of the field as its subviews become invisible to the accessibility frameworks. You can see and verify this is what is happening using the Accessibility Inspector app on the Mac alongside the simulator: the fields you are trying to target will not be selectable, and instead there will be a parent view that is.

I found the way around this best was to use menuItem and to paste what I wanted to the textField . This was a strange problem as both textField and staticText both didn't allow the test to run functionally. This is an issue I have reported to apple.

You can only use .typeText() on an input element. Static texts are not input elements - they're just text. Your addComment constant is probably the placeholder text within your text field. Tapping on the placeholder text probably activates the text field and keyboard, but you cannot call .typeText() on the placeholder text as the text field is its parent, not its descendant.

When this option is on, the Simulator doesn't bring up the soft keyboard, so the OS (sometimes) thinks the text field is not focused. Most of my tests have no problem typing in text fields with this option on, but some fail, especially search bars.

Another cause of this error is if there is a parent view of the text field in which you are trying to enter text that is set as an accessibility element (view.isAccessibilityElement = true). In this case, XCTest is not able to get a handle on the subview to enter the text and returns the error.

It isn't that no element has focus (as you can often see the keyboard up and blinking cursor in the UITextField), it is just that no element it can reach has focus. I ran into this when attempting to enter text in a UISearchBar. The search bar itself is not the text field, when setting it as an accessibility element, access to the underlying UITextField was blocked. To resolve this, searchBar.accessibilityIdentifier = "My Identifier" was set on the UISearchBar however the isAccessibilityElement was not set to true. After this, test code of the form:

The above answers solved it for me when running UI tests while the simulator UI is in the foreground (when you could see the changes in the simulator window). However, it did not work when running them in the background (which is how fastlane ran them, for example).

To be clear, I manually disabled-enabled-disabled the Hardware Keyboard in the Simulator Settings, set defaults write com.apple.iphonesimulator ConnectHardwareKeyboard 0, and then erased content and settings.

//XCUIApplication().scrollViews.otherElements.staticTexts["Email"] the locator for the elementRegistrationScreenStep1of2.emailTextField.tap()let keys = app.keys keys["p"].tap() //type the keys that you need //If you stored your data somewhere and need to access that string //you can cats your string to an array and then pass the index //number to key[] let newUserEmail = Array(newPatient.email()) let password = Array(newPatient.password) //When you cast your string to an array the elements of the array //are Character so you would need to cast them into string otherwise //Xcode will compain. let keys = app.keys keys[String(newUserEmail[0])].tap() keys[String(newUserEmail[1])].tap() keys[String(newUserEmail[2])].tap() keys[String(newUserEmail[3])].tap() keys[String(newUserEmail[4])].tap() keys[String(newUserEmail[5])].tap()

Your second line will dynamically execute the query and try to (re)bind the query to UI element. You should put a breakpoint on it and verify that one and only one element is found. Or just use an assert:

Don't messed up, There problem caught the reason is you are recorded your testing time your app will connection hardware keyboard while your automatic testing time simulator takes only software keyboard. so for how to fix this issues. Just use software keyboard on your recording time. you can see the magic.

We encountered the same error when setting the accessibilityIdentifier value for a custom view (UIStackView subclass) containing UIControl subviews. In that case XCTest was unable to get the keyboard focus for the descendent elements.

Another answer, but for us the problem was the view was too close to another view that a Gesture recognizer on it. We found we needed the view to be at least 20 pixels away (in our case below). Literally 15 didn't work and 20 or more did. This is strange I'll admit, but we had some UITextViews that were working and some that were not and all were under the same parent and identical other positioning (and variable names of course). The keyboard on or off or whatever made no difference. Accessibility showed the fields. We restarted our computers. We did clean builds. Fresh source checkouts.

Finally, I wrote a script which edits the Simulator's .plist file and sets the ConnectHardwareKeyboard property to false for the selected simulator. You heard it right, it changes the property for the specifically selected simulator inside "DevicePreferences" dictionary rather than editing the global property.

The thing is that -[UIApplicationSupport _accessibilityHardwareKeyboardActive] private method from com.apple.UIKit.axbundle sometimes returns NO even though it should return YES (when a text input view is firstResponder, and the cursor is blinking, which literally means that the hardware keyboard is active).

The problem for me was the same as for Ted. Actually if password field gets tapped after login field and hardware KB is on, software keyboard will dismiss itself on second field tap, and it's not specific to UI tests.

Create a script file with code above and add it to necessary targets(probably UI tests target only, you may want to add similar script to your development targets to re-enable HW keyboard during development).You should add Run Script phase in build phases and use it like this:osascript Path/To/Script/script_name.applescript

This show is orchestrated to be player conducted from the Keyboard 2 chair or you may opt to have a stick conductor. MTI provides a Key 2/Conductor score for the player option but also provides a separate K2 book and Full Score if your production opts for a separate K2 player and stick conductor. There are 3 keyboard books in this orchestration and all are very heavily programmed.

Keyboard 1 is the primary piano book and will require a very strong player. In addition to various acoustic pianos, the patches include many synth elements, percussion, strings, brass, celeste, harp, and harpsichord. The synth sounds in this and the other books are very specific although the patch descriptions may not reflect their specificity.

Keyboard 2 comes in 2 varieties. As mentioned, the first is a K2/Conductor score and the other is a K2 only book with none of the lyrics or vocal lines. They both contain the same patches. This books has a lot of auxiliary percussion sounds, orchestral woodwinds and brass, strings, B3 Organ, and many drum loops, one-shot samples, hits, risers, and many synth elements that are very specific and would be next to impossible to replicate. This book is not as difficult or technical as Key 1 but because of the amount of programming, you will need someone who is comfortable with playing a show that has lots of patches.

If you have obtained the performance rights for this show, please enter the Access Code provided to yourorganization by MTI to automatically verify your license and proceed to payment. If you do not have thisAccess Code or have not yet obtained the rights, you can still proceed by choosing your programming andfilling out the short form below. You will have an opportunity to upload your contract or have us manuallyverify your license prior to payment. Once that process is complete, you will receive an email with aninvoice and link for payment before receiving download instructions for the programming.

Based on the popular Disney Channel Original Movies, Disney's Descendants: The Musical is a brand-new musical jam-packed with comedy, adventure, Disney characters, and hit songs from the films!

The sound of Descendants: The Musical relies on an electronic landscape of pre-recorded drum loops and sound effects. The creators of the stage musical worked with KeyboardTEK to capture this sound in the live orchestrations, with specifically tailored programming for all 3 keyboard books. KeyboardTEK programming is highly recommended in order to produce the full sound of Descendants as intended by the authors.

The materials (which are yours to keep regardless of your organization type), consist of 30 Libretto/Vocal Books (script and songs for the actors), a Piano/Vocal Score, an Accompaniment Recording that features the back-up tracks to use in performance, and a Reference Recording that contains the full score performed by an ensemble of actors to help your cast prepare for the show.