AutoAcceptAlert is not working on IOS 16

[tburakdemir]

#540

Hi is there any chance to surpass this precise: on | off element.
I am using webdriveragent directly with defaultAlertAction: "accept" capabilities.

I have 2 ios device. iphone 7 ios 15.7.2 and iphone xs ios 16.2
The alert tests in integration app works as expected for both devices. But location permission for Maps or Camera apps is not working on iphone XS. The difference is that precise element i guess.

Above screenshots are from xs(16.2) Doesn't auto accept

This is from iphone 7(15.7.2). It is working as expected.

MacOs 13.3.1 (22E261)
WebdriverAgent v4.15.1 CommitID 3b48b6c

Cleaned build folder from xcode.
Remove webdriveragent and integration apps from device

[fleytman]

I have this problem too. @mykola-mokhnach @jlipps @KazuCocoa look pls to this problem

[KazuCocoa]

You could tune the target button logic with acceptAlertButtonSelector https://appium.github.io/appium-xcuitest-driver/4.33/settings/ since Appium/WDA tries to guess possible accept button as around

WebDriverAgent/WebDriverAgentLib/FBAlert.m

Line 187 in 2aee273

descendantsMatchingType:XCUIElementTypeButton].allElementsBoundByIndex;

but it cannot guarantee always accept as the iOS's element logic.

[jlipps]

@fleytman I'm not sure there is anything we can fix. There is no "standard" alert button text which we can hook into to guarantee correct behaviour in all cases. The right thing to do is as @KazuCocoa -- use the acceptAlertButtonSelector capability or setting so that Appium will be able to find the correct alert text.

[fleytman]

@jlipps @KazuCocoa

Thank you for your explanations. I would like to clarify a few important points:

1. I would like to know if the method you've suggested is capable of automatically determining the type of alert it is dealing with before performing any interaction.

2. Despite the provided recommendation, the current behavior that leads to infinite toggling between alert buttons remains unacceptable. Clearly, such behavior does not align with user expectations.

3. The idea of using acceptAlertButtonSelector sounds promising, but only if you are confident that the method can distinguish between different types of alerts automatically. Otherwise, there is a risk that this selector will be tied to the button text, which might vary for different alerts. Such a situation could result in the inability to interact with buttons on other alerts.

I would appreciate further clarification on these matters so that I can make the best decision for our project.

[KazuCocoa]

Understood.

We also hoped XCTest provided a good method to detect "accept" like always selecting "Allow Once" across OS versions/language preferences.

The current approach is to get buttons in an alert element and select the first button (as my previous comment's code link). It could be "Allow Once" in many cases, but actually location one is not. The number of buttons could depend on OS versions and alert implementation. This "implementation" includes user defined alerts as well. (btw, action sheet implementation in iOS is also handled as "alert", I haven't checked well recently, so it might be changed though)

Afaik, we also cannot detect if the alert is "location" permission across language preferences, so what we probably could do is just guess the alert's kind by counting the number of buttons. (maybe, I'm not sure how it is accurate. Probably when we can drop iOS 15, maybe could optimize some logic for iOS 16+, probably)

acceptAlertButtonSelector aims to give users to configure the button detection logic with class chain to customize the alert detection logic for their use case like text, element type, index or something.

[jlipps]

Yes, unfortunately there is no guaranteed way to always hit the positive/accept button on an alert without foreknowledge of the text that is displayed.

This means that, conceptually, there is no way for an auto accept alert feature to work in all cases. The sad fact is that developers can put any text they want on the buttons, and XCTest gives us no way to know which one is 'accept'.

My typical recommendation is not to rely on autoAcceptAlerts at all, but to configure the device beforehand not to show any unexpected alerts. Expected alerts would be dealt with explicitly in test code.