appium: handle "Paste from other apps" alert become extremely slow( cost 3 min) with wait.until(ExpectedConditions.alertIsPresent()) and base.getIosDriver().switchTo().alert().accept() after upgrading the xcuitest driver to version 6.0.0 (also tried version 7.1.0, same issue exists))
Do I have the most recent component updates?
- I use the most recent available driver/plugin and server versions
Is the component officially supported by the Appium team?
- I have verified the component repository is present under the Appium organization in GitHub
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
2024-02-20 03:33:16:234 - [HTTP] --> GET /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/text 2024-02-20 03:33:16:234 - [HTTP] {} 2024-02-20 03:34:16:644 - [HTTP] <-- GET /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/text 200 60411 ms - 110 2024-02-20 03:34:16:644 - [HTTP] 2024-02-20 03:34:22:450 - [HTTP] --> GET /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/text 2024-02-20 03:34:22:450 - [HTTP] {} 2024-02-20 03:35:22:748 - [HTTP] <-- GET /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/text 200 60298 ms - 110 2024-02-20 03:35:22:748 - [HTTP]
2024-02-20 03:35:22:751 - [HTTP] --> POST /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/accept 2024-02-20 03:35:22:752 - [HTTP] {} 2024-02-20 03:36:23:861 - [HTTP] <-- POST /session/2324dd1a-87cf-472d-97ec-8cbf70c6c40f/alert/accept 200 61110 ms - 14
Expected Behavior
Can get quick response when handle the alert as before.
e.g. on xcuitest driver version 5.16.1.
2024-02-21 01:59:11:114 - [HTTP] --> GET /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/text
2024-02-21 01:59:11:114 - [HTTP] {}
2024-02-21 01:59:11:244 - [HTTP] <-- GET /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/text 200 130 ms - 110
2024-02-21 01:59:11:244 - [HTTP]
2024-02-21 01:59:11:245 - [HTTP] --> GET /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/text
2024-02-21 01:59:11:245 - [HTTP] {}
2024-02-21 01:59:11:324 - [HTTP] <-- GET /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/text 200 78 ms - 110
2024-02-21 01:59:11:324 - [HTTP]
2024-02-21 01:59:11:325 - [HTTP] --> POST /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/accept
2024-02-21 01:59:11:325 - [HTTP] {}
2024-02-21 01:59:12:277 - [HTTP] <-- POST /session/a3b9be09-c7b6-4517-abfe-ca43a660ea3a/alert/accept 200 951 ms - 14
Minimal Reproducible Example
-
call base.getIosDriver().setClipboardText(text)
-
“Paste from other apps” permission dialog is triggered
-
use the following acceptAlert method to accept the alert.
public static boolean acceptAlert(TestBase base, long waitTimeInSec) {
if(base.isIOS()) {
WebDriverWait wait = new WebDriverWait(base.getIosDriver(), Duration.ofSeconds(waitTimeInSec));
try {
wait.until(ExpectedConditions.alertIsPresent());
base.getIosDriver().switchTo().alert().accept();
return true;
} catch (Exception e) {
System.err.println(" no alert visible after " + waitTimeInSec + " sec.");
return false;
}
}
return true;
}
- got really slow response for alert get/post command with xcuitest version 6.0.0
Environment
- Operating system: macOS Sonoma Version 14.2.1 (23C71)
- Appium server version (output of
appium --version
): 2.5.1 - Appium driver(s) and their version(s): xcuitest 6.0.0
- Appium plugin(s) and their version(s): execute-driver 3.0.25
- Node.js version (output of
node --version
):v18.10.0 npm
version (output ofnpm --version
):8.19.2- Last component(s) version which did not exhibit the problem: xcuitest 5.16.1 works fine, all the other envs are the same
- Platform and version under test: xcode 15.0.1, ios 17.0.1
- Real device or emulator/simulator: iOS simulator
- Selenium-java version 4.17.0
- Appium java-client version 9.1.0.
Link to Appium Logs
No response
Further Information
No response
About this issue
- Original URL
- State: closed
- Created 4 months ago
- Reactions: 1
- Comments: 21 (5 by maintainers)
@Dan-Maor The main difference between v5 and v6 version of the driver is that the logic for active app detection has been optimised. Now we assume the active app is always the app under test as soon as it is in Running foreground state instead of checking to which app a random on-screen pixel belongs. As far as I can understand in this particular situation with springboard alert shown xcuitest still marks the app under test as running in foreground (and thus it is selected as active) even though it is covered by the springboard alert (the springboard always has “running in foreground” state). This is also the reason why there was no delay in v5 - it did not even try to ask the app under test if it has an alert, but was requesting the springboard first. As a conclusion I would say it is not a bug, but a feature, because it also helps to figure out bugs in the app that cause blockage on the main run loop.
Thanks for providing the logs @Rosepotato It looks like the issue is
testmanagerd
hanging for 60 seconds trying to retrieve the main window in order to get accessibility information:I also noticed that you’re capturing a video during your test, and during the paste attempt screenshots are failing as well:
I wrote a simple app which access the UIPasteboard in a loop
on the main thread
and managed to reproduce the issue - testamangerd hanged. Accessing it from a block usingdetachNewThreadWithBlock
did not cause the hang.Accessing the pasteboard on the main thread of an app - given that UI operations and interactions (elements retrieval and screenshots) rely on the target application main queue to be idle - could be the reason for
testmanagerd
hanging.@Rosepotato Are you are you accessing
UIPasteboard
on the main thread of your application?