feat: add webviewAtomWaitTimeout to control timeout for the atom exec…

…ution (#2335)

* retry with reconnection

* recovery with reconnection

* add webviewAtomWaitTimeout

* fix lint

* >0

* correct docs

* rever the retry

* remove blank lines

* use a ternary op

docs/reference/capabilities.md

@@ -126,6 +126,7 @@ about capabilities, refer to the [Appium documentation](https://appium.io/docs/e
 |`appium:safariWebInspectorMaxFrameLength`| The maximum size in bytes of a single data frame for the Web Inspector. Too high values could introduce slowness and/or memory leaks. Too low values could introduce possible buffer overflow exceptions. Defaults to 20MB (`20*1024*1024`) |`1024`, `100*1024*1024` |
 |`appium:additionalWebviewBundleIds`|Array (or JSON array) of possible bundle identifiers for webviews. This is sometimes necessary if the Web Inspector is found to be returning a modified bundle identifier for the app. If the value includes `*`, XCUITest driver will return all available webview contexts on the device. Defaults to `[]`|`["io.appium.modifiedId', 'ABCDEF"]`, `["*"]`|
 |`appium:webviewConnectTimeout`|The time to wait, in `ms`, for the initial presence of webviews in MobileSafari or hybrid apps. Defaults to `0`|`5000`|
+|`appium:webviewAtomWaitTimeout`|The time to wait, in `ms`, for each atom execution timeout of webviews in MobileSafari or hybrid apps. Defaults to `120000`. If the value was zero or less, the timeout keeps the default value. |`20000`|
 |`appium:safariIgnoreWebHostnames`| Provide a list of hostnames (comma-separated) that the Safari automation tools should ignore. This is to provide a workaround to prevent a webkit bug where the web context is unintentionally changed to a 3rd party website and the test gets stuck. The common culprits are search engines (yahoo, bing, google) and `about:blank` |`'www.yahoo.com, www.bing.com, www.google.com, about:blank'`|
 |`appium:nativeWebTap`| Enable native, non-javascript-based taps being in web context mode. Defaults to `false`. Warning: sometimes the preciseness of native taps could be broken, because there is no reliable way to map web element coordinates to native ones. | `true` |
 |`appium:nativeWebTapStrict`| Enabling this capability would skip the additional logic that tries to match web view elements to native ones by using their textual descriptions. Depending on the actual web view content this algorithm might sometimes be not very reliable and will slow down each click as we anyway fallback to the usual coordinates transformation flow if it fails. It is advised to enable strict tap if you use [mobile: calibrateWebToRealCoordinatesTranslation](./execute-methods.md#mobile-calibratewebtorealcoordinatestranslation) extension. Only applicable if `nativeWebTap` is enabled. `false` by default | `true` |

lib/commands/web.js

@@ -773,9 +773,12 @@ const extensions = {
   async waitForAtom(promise) {
     const timer = new timing.Timer().start();
 
+    const atomWaitTimeoutMs = _.isNumber(this.opts.webviewAtomWaitTimeout) && this.opts.webviewAtomWaitTimeout > 0
+      ? this.opts.webviewAtomWaitTimeout
+      : ATOM_WAIT_TIMEOUT_MS;
     // need to check for alert while the atom is being executed.
     // so notify ourselves when it happens
-    const timedAtomPromise = B.resolve(promise).timeout(ATOM_WAIT_TIMEOUT_MS);
+    const timedAtomPromise = B.resolve(promise).timeout(atomWaitTimeoutMs);
     const handlePromiseError = async (p) => {
       try {
         return await p;

lib/desired-caps.js

@@ -306,6 +306,9 @@ const desiredCapConstraints = /** @type {const} */ ({
   webviewConnectTimeout: {
     isNumber: true,
   },
+  webviewAtomWaitTimeout: {
+    isNumber: true,
+  },
   iosSimulatorLogsPredicate: {
     isString: true,
   },