Alert handling - is there a way to determine if an alert is present?

1,519 views
Skip to first unread message

Christopher Graham

unread,
Jun 26, 2014, 5:50:19 PM6/26/14
to appium-...@googlegroups.com
Appium 1.1.0 + Python 2.7  + latest Python bindings + iOS7 Simulator


My app invokes a variety of UIAAlert  dialogs for network errors, authentication failures, etc.  Some of them appear at expected times during my testing, others can theoretically appear at any given time.  Right now I'm focused on the expected alerts, such as entering invalid login credentials and wanting to validate an "Authorization Failure" dialog appears. I'm struggling with determining how to best handle these various UIAAlert dialogs.

For starters, I cannot figure out how to successfully determine if an alert is even truly present. The following code ALWAYS returns an Alert object such as <selenium.webdriver.common.alert.Alert object at 0x102801f50> even if an alert is not physically displayed.

self.driver.switch_to.alert

So if I throw it in a try / catch block in an effort to write a function that will determine if an alert is present, it's always returning True since there's always an Alert object returned even when an alert is not physically available.

    def is_alert_present(self):
        try:
            alert = self.driver.switch_to.alert
            return True
        except:
            return False


> Run scripts which invoke an alert, I see it on screen, Appium inspector finds it, it's in the page_source XML
> is_alert_present()   returns True
> Physically dismiss the alert
> is_alert_present()   still returns True
> page_source absolutely has no UIAAlert (or anything else alert related) in the XML, it physically does not exist

Am I going about this the wrong way?

Loren Smith

unread,
Jul 18, 2014, 12:25:41 PM7/18/14
to appium-...@googlegroups.com
I'm having a similar issue and am curious to know if you've found any methods to get around this?

This email message is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

Keegan Parker

unread,
Jul 18, 2014, 1:39:04 PM7/18/14
to appium-...@googlegroups.com
You may want to try is_displayed() or is_active() methods.

Christopher Graham

unread,
Jul 18, 2014, 3:28:28 PM7/18/14
to appium-...@googlegroups.com


On Friday, July 18, 2014 1:39:04 PM UTC-4, Keegan Parker wrote:
You may want to try is_displayed() or is_active() methods.




Ouch. I haven't seen those functions provided on my end using Python and the Appium-Python-Client. 

I did just remember theres a .text property that pulls the title and body text from the UIAAlert dialog though.  I'd have to go back and check but my recollection was it pulled it all in one lump without any delimiter between the title and body text. 

Christopher Graham

unread,
Jul 18, 2014, 3:30:10 PM7/18/14
to appium-...@googlegroups.com
My conclusion is that the switch_to.alert and then alert.dismiss()  are intended as a blind process to dismiss any UNEXPECTED alert dialogs the system may throw at you (I think there was some language indicating this on one of the resources I read way back when), but not at all intended to handle AUT generated dialogs that may just so happen to be using a UIAAlert type dialog.

What I've gone to creating my own functions to check for EXPECTED alert dialogs.  In one specific case, on a new installation my AUT invokes an UIAAlert dialog to display a "What's New" dialog that details some of the changes to the app, and has a single "OK" button.  I could in fact use   alert.dismiss()  to blindly dismiss it as it opens each time a new install completes. But this doesn't help me understand if the "What's New" dialog was present to begin with, or whether it truly closed or not since there's no related function to check for alert existence. 

So where I'm at is coding generic functions for the following:

* does element exist
* explicitly wait for element to exist, set to a max_wait timer to prevent infinite loops
* does dialog exist (checks for multiple expected dialog elements to exist, I haven't devised a better way yet)
* explicitly wait for dialog to open
* explicitly wait for dialog to close

Between all of those attributes and functions I can theoretically have much more robust scripts that can detect if particular dialogs exist (whether they're using UIAAlert or not), and I can utilize intelligent explicit waits instead of hard coded time.sleep()  or a long global implicitly_wait()   that slows *everything* down.

Hope this helps, keep in mind I'm new at Appium so there could be better ways at doing things. I love it when people correct me so correct my steering if I'm going the wrong direction. :)

Loren Smith

unread,
Jul 18, 2014, 5:05:57 PM7/18/14
to appium-...@googlegroups.com
It seems like 'autoAcceptAlerts': 'true' capability would be used to dismiss any alert (expected or not).  When I expect an alert to pop, I've been using switch_to_alert to grab the alert text and inspect if it contains the message I think it should.  

What I'm having trouble with (perhaps this is because I'm new to both Appium and Python) is how to asynchronously check for alerts.  How do you not fail a test due to an unexpected alert without wrapping each command with a check to see if an unexpected alert is shown?  

I'm probably missing some big Appium capability, but I can't seem to find anything that suggests there's a method out there.



--
http://appium.io
---
You received this message because you are subscribed to a topic in the Google Groups "Appium-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/appium-discuss/1KXJmI3XiRE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to appium-discus...@googlegroups.com.
Visit this group at http://groups.google.com/group/appium-discuss.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages