Temporarily disable autoAcceptAlerts for appium and then re-enable

zfighter876 2016-10-03 05:28:20 UTC #1

So currently I understand that autoAcceptAlerts is a desired capability for iOS. If I set this desired capability to "true" when creating the appium driver all alerts gets accepted as expected.

However, what I would like to do is midway through the app there is an alert I don't want to immediately auto-accept. Rather I would like to enter something into the alert text box, press the "Set" button and continue forward. And from everything after that point all alerts should be accepted.

Effectively I want to temporarily disable autoAcceptAlerts and then re-enable it. Is there a way to do this in appium?

Venkatesh 2016-10-04 09:32:34 UTC #2

Even I am looking for a solution on this, let me know if you get a workaround.

Aleksei 2016-10-04 11:37:59 UTC #3

the only way is - remove autoAccept and manage all by yourself

zfighter876 2016-10-05 17:16:13 UTC #4

So thinking about it some more it may make sense to remove autoAcceptAlerts and just manage all the alerts ourselves which is fine so that we have complete control over alerts.

However, this does raise a question for me:

So I was looking at some of the appium documentation here: https://github.com/appium/appium/blob/master/docs/en/advanced-concepts/settings.md

And from the documentation it looks like desired capabilities and settings are completely different concepts. However, what I found odd was that some of the supported settings that are run-time configurable such as "ignoreUnimportantViews" are a setting that can be run-time configurable but are also a desired capability based on the docs here:

github.com

appium/appium/blob/master/docs/en/writing-running-appium/caps.md

## Appium server capabilities

<expand_table>

|Capability|Description|Values|
|----|-----------|-------|
|`automationName`|Which automation engine to use|`Appium` (default) or `Selendroid`|
|`platformName`|Which mobile OS platform to use|`iOS`, `Android`, or `FirefoxOS`|
|`platformVersion`|Mobile OS version|e.g., `7.1`, `4.4`|
|`deviceName`|The kind of mobile device or emulator to use|`iPhone Simulator`, `iPad Simulator`, `iPhone Retina 4-inch`, `Android Emulator`, `Galaxy S4`, etc.... On iOS, this should be one of the valid devices returned by instruments with `instruments -s devices`. On Android this capability is currently ignored, though it remains required.|
|`app`|The absolute local path _or_ remote http URL to an `.ipa` or `.apk` file, or a `.zip` containing one of these. Appium will attempt to install this app binary on the appropriate device first. Note that this capability is not required for Android if you specify `appPackage` and `appActivity` capabilities (see below). Incompatible with `browserName`.|`/abs/path/to/my.apk` or `http://myapp.com/app.ipa`|
|`browserName`|Name of mobile web browser to automate. Should be an empty string if automating an app instead.|'Safari' for iOS and 'Chrome', 'Chromium', or 'Browser' for Android|
|`newCommandTimeout`|How long (in seconds) Appium will wait for a new command from the client before assuming the client quit and ending the session|e.g. `60`|
|`language`| (Sim/Emu-only) Language to set for the simulator / emulator |e.g. `fr`|
|`locale`| (Sim/Emu-only) Locale to set for the simulator / emulator |e.g. `fr_CA`|
|`udid`| Unique device identifier of the connected physical device|e.g. `1ae203187fc012g`|
|`orientation`| (Sim/Emu-only) start in a certain orientation|`LANDSCAPE` or `PORTRAIT`|
|`autoWebview`| Move directly into Webview context. Default `false`|`true`, `false`|
|`noReset`|Don't reset app state before this session. Default `false`|`true`, `false`|
|`fullReset`|(iOS) Delete the entire simulator folder. (Android) Reset app state by uninstalling app instead of clearing app data. On Android, this will also remove the app after the session is complete. Default `false`|`true`, `false`|

This file has been truncated. show original

So my question is then does it make sense to make have a desired capability such as autoAcceptAlerts as a run-time configurable setting? Or was the example above a one-off that we shouldn't follow?

Any thoughts would be greatly appreciated?