SafariDriver cannot handle alerts

[lukeis]

Originally reported on Google Code with ID 3862

Filing this bug to track the implementation of alert handling in the SafariDriver.

Here are the steps I've worked through so far:

--- Step 1
Since the SafariDriver is implemented in JS, in order to intercept calls to alert,
confirm, and prompt, we must override the functions in the context of the web page.
 To achieve this, we should change the injected script to be injected as a "Start"
script instead of "End" script - which means the script is injected once the DOM has
been loaded, but before it has been parsed (as opposed to being injected after the
onload event):

http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/InjectingScripts/InjectingScripts.html#//apple_ref/doc/uid/TP40009977-CH6-SW5

---- Step 2
We must override the global alert functions in the context of the page under test,
_not_ the injected script. This is similar to the requirements of the executeScript
command.  Therefore, the first thing our injected script should do is add a script
tag to DOM that sets up the alert overrides. This script tag should be added as the
first child of the documentElement to ensure it is executed before any others in the
page. This will ensure we set-up our alert handlers before anything in the page has
a chance to fire an alert.

---- Step 3
Once an alert fires, we must notify the extension that there was an alert, while simultaneously
blocking the current JS thread in the page.  Normally, our page scripts communicate
with the injected script using window.postMessage. postMessage fires a MessageEvent
asynchronously.  To maintain synchronicity, we can manually fire a MessageEvent:

// Use a MessageEvent instead of some other DOM event so we can include a
// JSON object describing the alert.
var event = document.createEvent('MessageEvent');
event.initMessageEvent('message', false, false, {
  type: "alert",  // confirm, or prompt
  text: "hello"
}, window.location.origin, '0', window, null);
window.dispatchEvent(event);

---- Step 4
The injected script must listen for an respond to the page's alert message.  To synchronously
send the alert to the extension for processing, we can (ab)use the Safari extension's
mechanism for blocking content from loading:

http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9

window.addEventListener('message', function(e) {
  // Create a beforeload event, which is required by the canLoad method
  var e = document.createEvent('Events');
  e.initEvent('beforeload', false, false);

  // canLoad sends and waits for a response synchronously. It is the only
  // synchronous function in the Safari extension messaging API.
  var response = safari.self.tab.canLoad(e, e.data);

  // Send the response back to the page using another MessageEvent.
  var responseEvent = document.createEvent('MessageEvent');
  responseEvent.initMessageEvent('message', false, false, {
    accepted: response.accepted,
    response: response.value
  }, window.location.origin, '0', window, null);
  window.dispatchEvent(responseEvent);
}, true);

Note, the extension's alert response must be communicated back to the page using another
message since we are crossing context boundaries. The only other option is to store
the response on the DOM to be read on the other side.

---- Step 5
The final step, and this is the open-ended question, is how the extension should handle
the alert.  Since we're maintaining the blocking behavior of alerts, it's not possible
to let anymore commands execute (even if they result in unhandled alert errors).

One possibility is to have the WebDriver client participate in the alert handling.
 In addition to providing a WebSocket server, the WebDriver client will be expected
to also provide an XHR end-point.  When an alert is detected, the server will send
a synchronous POST XHR to this end-point.  The client should respond only once the
user has accepted or dismissed the alert (or an unhandled alert error was thrown from
another command).  When the XHR response is received, the extension completes the chain
and sends the response back to the injected script.

---------------------------------

Yes, this is going to be ugly, but it should be doable.  On the off chance anyone wants
to help get this worked out, I've attached a patch with my work on this front.

Reported by jmleyba on 2012-05-07 16:44:15

---

- _Attachment: [alerts.diff](https://storage.googleapis.com/google-code-attachments/selenium/issue-3862/comment-0/alerts.diff)_

[lukeis]

Reported by jmleyba on 2012-05-07 16:46:54

• Labels added: GettingInvolved

[lukeis]

Reported by jmleyba on 2012-05-20 18:57:43

• Labels removed: GettingInvolved

[lukeis]

Even though we can synchronously catch the alert and let the extension know about it,
there's no way for the extension to wait for the client to handle the alert.  The extension's
JS runs in the UI thread, so if we try to block for too long, Safari will kill our
extension and trigger an unresponsive script error.

Sadly, this means the SafariDriver will not be capable of handling alerts.

Reported by jmleyba on 2012-05-27 01:48:38

• Status changed: WontFix

[lukeis]

Aside from not being able to handle/test for alerts, prompts, and confirmations, does
this affect anything else with WebDriver tests? I mean will the lack of this feature
cause WebDriver tests to hang/fail when an alert appears on the screen (even though
you can't do anything with it with SafariDriver), or will it just be ignored and the
test can continue?

Just wondering if a user can have a single set of WebDriver tests but with browser
check in code and if browser is Safari, skip testing/checking for alerts in the tests.
Or if user has to add additional workaround to not even do any test flow that will
generate alert else test might hang/fail for Safari.

Asking this as I'm not yet well familiar with WebDriver alert handling but know that
in Selenium RC, if you don't handle the alert, test may fail.

Reported by mangaroo on 2012-05-27 03:12:13

[lukeis]

See issue 3969 :-)

Reported by jmleyba on 2012-05-27 03:56:19

[lukeis]

Actually, I'll just merge it into this one.

Reported by jmleyba on 2012-05-27 03:57:46

• Status changed: Accepted

[lukeis]

Issue 3969 has been merged into this issue.

Reported by jmleyba on 2012-05-27 03:58:01

[lukeis]

Sorry for being a bit indecisive here. I'm going to track the two issues separately
after all.

Reported by jmleyba on 2012-07-03 17:52:29

[lukeis]

This issue was updated by revision r17316.

The SafariDriver still cannot handle alerts, but it will now dismiss any that open,
preventing a test from hanging.

Reported by jmleyba on 2012-07-03 18:49:04

[lukeis]

This bug is as fixed as it probably can be, but I'm going to leave it open in case someone
else thinks of a way to improve things.  I'm also going to remove myself as the owner
since I will no longer be actively working on this bug.

Reported by jmleyba on 2012-07-03 18:51:20

[lukeis]

Reported by jmleyba on 2012-07-21 18:50:41

• Status changed: NotFeasible

[lukeis]

Issue 4379 has been merged into this issue.

Reported by barancev on 2012-08-08 22:01:57

[lukeis]

Issue 4380 has been merged into this issue.

Reported by barancev on 2012-08-08 22:02:22

[lukeis]

Thought I'd share a code snippet post for novice users who aren't familiar with this
issue. Here's an example of how you would workaround this Safari issue:

/**
* Confirm alert, prompt, or confirmation dialog that is present on the page.
* Does nothing if confirmation not present on page and returns empty string.
* @return String        alert text or empty string
*/
public String getConfirmation() {       
    try{
        Alert alert = driver.switchTo().alert();
        String alertText = alert.getText();
        alert.accept();
        return alertText;       
    }catch(Exception ex){
    //}catch(UnexpectedAlertOpenException ex){ //assume this is the correct exception
to detect in Safari, per issue 3969? I haven't tested yet.
    //}catch(NoAlertPresentException ex){
        return ""; //if there is no alert displayed, do nothing, return empty string.
    }
}

By the way, related issue 3969 appears fixed in Selenium v2.25.0 based on revision
date, which I am not on yet, so haven't tested new behavior. But on v2.24.1 (and older),
whether you check for alert or not, an actual visual alert prompt will show up on Safari
browser, causing test to hang without manual intervention. And thus to workaround that,
a test must do a check for browser == Safari and then skip the actions that trigger
alert to show up in the first place. Hopefully 3969 addresses that so the hang won't
be there whether you check for alert or not, but your test code does trigger alert
regardless (i.e. normally alert prompt would appear).

Reported by mangaroo on 2012-08-08 23:43:40

[lukeis]

Issue 4910 has been merged into this issue.

Reported by jmleyba on 2012-12-15 01:11:27

[lukeis]

Just curious: Have you guys tried contacting Apple to get some of these restrictions
removed so that SafariDriver can have the same capabilities as the drivers for other
browsers? This kind of stuff is a big deal for integrated cross-platform testing.

Reported by google@zetafleet.com on 2013-03-05 03:43:31

[lukeis]

On this particular issue, no.  This falls within the design restrictions of Safari browser
extensions.  Unfortunate for our purposes, but understandable nonetheless.

Reported by jmleyba on 2013-03-05 05:08:56

[lukeis]

FYI, thought I'd mention this tip: if one needs to handle the alert (say accept over
cancel in an alert prompt) to proceed correctly in the test, for Safari workaround,
you can look into how your web app/site operates. 

For our sites, the alerts when accepted usually trigger an HTTP/AJAX call to the server
to do something and then the page or a portion of it refreshes. For a Safari workaround
in that case, I just made pure HTTP requests (in one's language platform) to the server
externally from Selenium then manually do a page refresh afterwards to verify whatever
operation completed successfully (after first checking HTTP response returned from
the HTTP request). That way we could continue with the test w/o skipping over some
needed functionality in the overall test flow.

I would assume for others where the alert triggers some local javascript execution
instead of AJAX calls, the workaround is to manually trigger those javascript calls
instead.

Reported by mangaroo on 2013-03-05 05:41:10

[lukeis]

I am using selenium server standalone.jar file but still getting alert issues for safari
browser.
Exception in thread "main" org.openqa.selenium.UnhandledAlertException: A modal dialog
was opened. The SafariDriver does not support interacting with modal dialogs. To avoid
hanging your test, the alert has been dismissed.

Reported by sweetgirl.ani13 on 2013-03-11 09:43:53

[lukeis]

@sweetgirl.ani13 That is the expected behavior. The SafariDriver does not support interacting
with alerts. It must dismiss them immediately or it will hang.

Reported by jmleyba on 2013-03-11 18:17:38

[lukeis]

Can we also clarify what we mean by alert being dismissed automatically? Is that equivalent
to clicking OK/Yes or No/Cancel in an alert dialog that shows up in other browsers.
No/Cancel of course will simply be "OK" in a single button alert dialog.

Reported by mangaroo on 2013-03-11 21:06:25

[lukeis]

It's standard webdriver behavior: dismissed = OK (alert), Cancel (confirm/prompt).

Expected JS return values:
alert() => undefined
confirm() => null
prompt() => false

Reported by jmleyba on 2013-03-12 02:04:06

[lukeis]

Issue 5618 has been merged into this issue.

Reported by jmleyba on 2013-05-09 17:16:49

[lukeis]

Closing this issue is not particularly acceptable.  Modal alerts are very common in
web applications and the current safari driver standalone server does not dismiss the
alert as described above.  It ignores it and intercepts even a manual click on the
element that triggers the alert.  It does not do the 'standard webdriver behavior'
and dismiss with an 'OK'.  

functionality controlled by that element is completely unavailable while the standalone
server is running.

An example can be seen in salesforce.com.  Start the standalone server. Log in and
go to accounts.  Add an account, save it, re-open it and try to delete it with the
standalone server running...  Nothing happens when the delete button is clicked because
the alert has been intercepted and essentially sent to dev/null...  This makes testing
of the delete functionality, or perhaps a cancel that raises an alert, impossible to
automate.  

Again, not really acceptable, especially when the same situation works ok in windows
under ie, firefox, and chrome.  (I haven't tried chrome on Mac just yet).

If handling modal alerts, especially js modal alerts were a true corner case I wouldn't
make much of a fuss.  Show me a significant business application, inside or outside
enterprise firewalls that doesn't ever use one and I'll show you a very flawed application
design.  Not forcing confirmation of an action that can't be undone is not defensible
and may well be actionable.

Reported by patrick@3qilabs.com on 2013-06-27 19:10:35

[lukeis]

And, by the way, the exception that is thrown forces scripts (at least in ruby using
watir-webdriver and selenium-webdriver) to catch it in order to go on.  Makes cross-browser
automation just a bit more fun.

Reported by patrick@3qilabs.com on 2013-06-27 19:14:14

[lukeis]

Alerts are intercepted via JS, so they must be handled immediately or the UI thread
will hang (blocking the entire browser, including the driver). Since we do not have
prior knowledge on how to handle alerts, they are dismissed and an error is returned
to the client.  This gives tests a chance to finish.

Alert handling is one of the more complicated bits of the SafariDriver's implementation.
If you feel so strongly about it, feel free to put together a patch changing the driver's
behavior.

Reported by jmleyba on 2013-07-02 03:07:05

[lukeis]

I understand that they block the browser.   In windows, at least with
Watir, and Watir-webdriver with Firefox,  the browser is, of course
blocked, but the test script is not, allowing OS tools (like AutoIt) to be
used to dismiss the alert if the webdriver can't.   This solution of
blowing it away invisibly removes the option of handling the alert with a
choice (OK/Cancel)  and testing the application's response to each option.

Had I the experience with js, etc. I would try to contribute.  But I also
don't have the spare cycles.

Please give it a bit more priority.

pat

Reported by patrick@3qilabs.com on 2013-07-02 03:49:45

[lukeis]

Let's add more context to this latest discussion...

Correct me if I'm wrong. So I'm assuming that with the current SafariDriver design,
if some particular automation action results in an alert, if we don't (automatically)
handle alerts it will hang the Safari browser and the SafariDriver, meaning you can't
issue the next Selenium command once the alert pops up and isn't handled (hung test
script). 

Also, will alert pop ups show visibly in the Safari browser if not automatically handled
(or they'll be invisible)?

If my assumption is correct, and assuming the technical feasibility (at present) doesn't
allow for a different design where the browser may hang but not the driver, and if
alerts will/can show visibly then maybe we can offer an option for the Selenium user
to handle the alert externally with AutoIt, etc. as in comment 27. 

And if the driver hangs when browser hangs at showing of alert, then it would be up
to the Selenium user to know when to expect the alert and as such they should use threads
(in code) to execute the Selenium command(s) that result in the alert such that that
thread hangs but not the main or other thread to which can use to execute AutoIt, etc.
which would then resume the hung thread. Or instead of using threads, have some polling/watching
process external to the test script that checks for alert dialogs and handles them
with AutoIt, etc.

With the suggestion above, I'm suggesting we offer some SafariDriver startup option
to automatically handle alerts or not, so the user can decide how they want to deal
with alerts in Safari. But this only applies if alerts are actually visible to handle
by external tools when they're not auto handled by the driver.

Reported by mangaroo on 2013-07-02 21:53:59

[lukeis]

1. If we don't handle an alert the moment it opens, Safari and the SafariDriver will
both block.  If the alert opened between commands, the next command you send will never
been received.  If the alert opens while executing another command, the driver will
never be able to send the response to that command.

2. The SafariDriver overrides the alert functions (alert, confirm, prompt, onbeforeunload)
so the native version never gets called.  The moment the native code is called, the
browser hangs. This means you will never see the dialog open while watching an automated
test.


I'm not comfortable adding an option to completely disable alert handling. Someone
will inevitably use it and then complain that their test hangs.  We can add support
for configuring whether Safari automatically accepts or dismisses alerts (defaulting
to dismiss), and what value to return when accepting.  We could probably also support
dynamically changing this behavior, but this will be trickier since it will require
a non-standard API, meaning test code wouldn't be consistent between browsers.

Reported by jmleyba on 2013-07-03 17:55:30

[lukeis]

Actually it is the SafariDriver behavior that differs from the other drivers.  In IE,
Firefox, and Chrome, the Alert class works.   A click is performed that is known to
raise an alert and then then Alert.ok or .dismiss or .cancel can be called to close
the alert with the desired result using webdriver.   These do not require the use of
AutoIT.  

Reported by patrick@3qilabs.com on 2013-07-05 16:53:56

[lukeis]

"We can add support for configuring whether Safari automatically accepts or dismisses
alerts (defaulting to dismiss)"

Please do so. Because Now there is not way to continue the test if there is an alert.
There are a lot of users of Safari and the ability of test application in Safari will
be greatly appreciated. 

Reported by jannatulferdaush on 2013-08-22 17:33:13

[lukeis]

FYI, since I had one request for it, here's a Java example of how you'd do the HTTP
library workaround for alert handling for Safari, if it's doable for your web application
under test:

https://gist.github.com/daluu/6758854

Reported by mangaroo on 2013-09-30 02:56:20

[lukeis]

David, I went through your sample code but it doesn't apply for my case, so I have to
find another solution, but the bottom line is we cannot simply skip the alert/confirmation/prompt
verification in our testing. And these days I found a new problem is when SafariDriver
starts a browser session, if I manually play around the alert stuff in the browser,
it seems that the alert is disabled by SafariDriver, means I cannot see the alert popup
in the app, but it doesn't behavior so I manually start the Safari browser. So I wonder
if it's the SafariBrowser does something to dismiss it by default, if yes seems it
also block the application to move forward the request.

So first I wonder if SafariDriver can enable the alert back in the app, then we can
figure out how to handle it by the workaround.

Reported by shenxieyin on 2013-10-12 09:51:18

[lukeis]

This thought just came to me, I don't know the state/status of alert handling in mobile
Safari on Appium and ios-driver (mobile Safari deprecated in Selenium project), but
assuming that works, if one needs to test on Safari that involves alerts, then perhaps
one workaround is to test against mobile Safari instead (via iOS simulator on Mac or
SauceLabs).

It's not a perfect workaround but mobile Safari is based on or similar to desktop Safari,
so it could be close enough to test against with respect to Safari and alerts.

Just thought I'd mention it.

Reported by mangaroo on 2013-10-13 02:43:21

[lukeis]

What's the mobile Safari, is it a different Safari driver outside of selenium jar or
not? Kindly can you point it to me?

Reported by shenxieyin on 2013-10-14 02:32:56

[lukeis]

Yes, mobile Safari is a driver outside of the Selenium JAR, requires an alternative
Selenium server (that's not necessarily a JAR) but you can use the same client language
bindings.

For mobile Safari, I don't think there's a nice tutorial resource for everything but
these links are a starting point:

(deprecated)
https://code.google.com/p/selenium/wiki/IPhoneDriver

(non-deprecated)
http://sauceio.com/index.php/2013/04/mobile-test-automation-in-java-with-appium/
https://github.com/appium/appium/blob/master/docs/running-tests.md#run-ios
http://ios-driver.github.io/ios-driver/safari.html

Reported by mangaroo on 2013-10-14 04:15:53

[lukeis]

Thanks for the share, but looks like it doesn't resolve our problem, so I'd still hope
first AT LEAST have the SafariDriver to involve the alert in the app, that makes the
app behavior correct for the automation testing, otherwise we cannot move forward.

Reported by shenxieyin on 2013-10-14 09:03:57

[lukeis]

"We can add support for configuring whether Safari automatically accepts or dismisses
alerts (defaulting to dismiss)"

I'd also like to see this implemented whenever time permits.

Reported by bart.morantte-archive@everyonecounts.com on 2013-11-20 03:48:11

[lukeis]

jmle...@gmail.com  , can u explain how to use the "alert.diff" , thanx in advance, sry..
am new to safari driver automation

Reported by sashankgangi on 2013-11-27 07:25:48

---

- _Attachment: [alerts.diff](https://storage.googleapis.com/google-code-attachments/selenium/issue-3862/comment-39/alerts.diff)_

[lukeis]

Hi, as other people have noted that the dismiss-alerts behavior is not really acceptable
in some automation scenarios (best to be at least configurable), I want to ask if it
is feasible as a workaround to create a Safari extension that can intercept such an
alert before Selenium SafariDriver kicks in. In this way, the extension can be configured
to handle more complex scenarios. Any thoughts?

Reported by immitev on 2013-12-20 10:02:23

[lukeis]

On comment #40, what do you mean, can you elaborate? If you mean intercept the way SafariDriver
kind of does it but handle differently, then I don't think that's really feasible or
a good design because that would be like having 2 SafariDrivers running but one doing
something else and taking higher priority.

If implemented differently, not based on WebDriver (or how SafariDriver is implemented),
that might be possible, but based on what Apple offers you in terms of Safari extension
API/development, you are really limited in what you can do. Much different than say
with FF/Chrome extensions and even more so IE addons which can make use of things like
COM/ActiveX for lower level functionality closer to OS integration. Apple doesn't offer
you that kind of thing, restricting you to somewhat sandboxed javascript.

Reported by mangaroo on 2013-12-20 20:10:32

[lukeis]

To elaborate, I wondered if there is a mechanism in Safari that's more powerful than
what the SafariDriver is using. From your answer I understand that this is not the
case. So it seems that the only way to have more complex handling is via low-level
mechanisms that simulate user behavior. This should probably include detection of popup
windows, extraction of the text via some OS-specific API and/or OCR, and then simulating
mouse-clicks.

Reported by immitev on 2014-01-06 14:21:26

[lukeis]

Yes, and that would mean a different/new SafariDriver be built from a different architecture
than the current one (Safari browser extension). One could take a look at what's available
in the old Selenium code repository. The original SafariDriver that was being worked
on (and never released I think) was an XCode project, so that seems more low level.
Or create from scratch...

Reported by mangaroo on 2014-01-06 20:39:59

[lukeis]

Issue 7074 has been merged into this issue.

Reported by barancev on 2014-03-12 09:27:38

[lukeis]

Issue 7380 has been merged into this issue.

Reported by jmleyba on 2014-05-22 20:54:33

[lukeis]

I have an issue that may be related to this that I can't seem to get past.  I'm trying
to click a "Submit" button on a login web page.  If I manually login using Safari with
VALID credentials I see no alert dialogs.

However using SafariDriver, it throws the UnhandledAlertException.  If I try to manually
handle any alert that might be present, I get what I expect, a NoAlertPresentException.

The code is below.  The problem is that no matter what I do, when I attempt to click
the submit button, I get an exception and the button/form is never submitted so I am
never able to log in.  

Since I don't see an alert when manually interacting with the login form, I don't know
what to look for.  Any thoughts?

I'm using the Selenium-java 2.43.1.

METHOD:
public void login(String username, String password) {
        username_input.clear();
        username_input.sendKeys(username);
        password_input.clear();
        password_input.sendKeys(password);

        try {
            Alert alert = sb.driver.switchTo().alert();  //THROWS NoAlertPresentException
            alert.accept();
        } catch (Exception ex) {
            String msg = ex.getMessage();
            System.out.println(msg);
        }

        try {
            submit.click();   //THROWS UnhandledAlertException
        } catch (Exception ex) {
            String msg = ex.getMessage();
            System.out.println(msg);
        }
    }

Reported by PredatorVI on 2014-10-28 16:56:57

[lukeis]

For comment 47, do alerts occur with any other browser? That might help diagnose the
issue if you can see or figure out what the alert is about. There is no good way to
handle alerts in Safari, so the best approach in testing is to avoid the action that
triggers the alert where possible.

Reported by mangaroo on 2014-11-01 00:34:13

[lukeis]

Hi jmle,

I found I cannot set the alert behavior to accept, by the way of 
DesiredCapabilities capabilities = (DesiredCapabilities)DesiredCapabilities.Safari();
                    capabilities.SetCapability("unexpectedAlertBehaviour", "accept");

The case is that when I click delete button, it popup a dialog to confirm the deleting,
I need to click 'OK', it always got the exception that 'UnhandledAlertException, the
safaridriver does not support interacting with modal dialogs', is there any way that
I can confirm the alert and get my test passed?

Reported by windgone9 on 2015-01-26 09:54:51

[lukeis]

I missed/overlooked comment 39 earlier. Someone also asked about alerts.diff in webdriver
Google group post today. So here's a recap of my response:

To use it, you will most likely have to build the SafariDriver extension yourself,
replacing the original/current alerts code/file (javascript/safari-driver/message.js)
with the diff version. You have to manually replace/merge the code into the original
source code you pull from Google Code or GitHub. Then build the extension, and install
that into Safari manually, and/or when instantiating SafariDriver, tell it via the
capabilities to not install the extension automatically (use the manually pre-installed
version you installed) or to install a custom extension you supply. Because the default
extension bundled with the JAR won't have the diff code in it.

Here's some info about installing the extension when starting the driver via capabilities
and how to build the extension from source. Direct email me if you have issues/questions
with building from source. I've done it before. FYI, you'll likely need a Mac to build
it, as Apple dropped Windows support for Safari. Although you can still run SafariDriver
on Windows, you just can't officially build on Windows.

https://code.google.com/p/selenium/wiki/DesiredCapabilities#Safari_specific
https://code.google.com/p/selenium/wiki/SafariDriverInternals
https://rationaleemotions.wordpress.com/2012/05/25/working-with-safari-driver/

Reported by mangaroo on 2015-01-27 20:27:31

[lukeis]

Is this tested? has there yet been any pull request?

Reported by dangerwillrobinsondanger on 2015-04-21 07:33:09

[lukeis]

We are also facing same issue on safari web driver(selenium-server-standalone-2.45.0.jar).
The JavaScript dialog box getting suppressed(not visible) and getting exception like
"Alert not found" in case of alert dialog box.
But when we execute test case manually an alert box is not suppressed(visible).
This issue occurs on both MAC and WINDOW platform.
Requesting to provide good workaround for this issue.

Thanks,
Baban

Reported by bdkakde on 2015-05-06 09:38:46

[lukeis]

For comment #51, I doubt that the diff patch has been really tested by anyone, especially
outside of Selenium developers. But one is welcome to try it.

For comment #53, the workarounds are already mentioned in this issue thread. A summary
recap of available workarounds:

* try using the patch attached to this issue (manually build extension & install, merging
the patch code to the SafariDriver source)

* avoid triggering the alert in the first place, bypass it, or simulate/fake the alert.
E.g. if the alert will trigger an AJAX call, just make the AJAX call directly from
a HTTP library (outside Selenium) instead of triggering the alert to do it.

* use external tools like Java Robot class, AutoIt, or Sikuli to complement this limitation
of SafariDriver

* use or build alternate "SafariDriver" tools. (1) There was one (more native) prototype
SafariDriver that was implemented differently than the current one, but that prototype
was never completed, though it's source code I think should be in the Selenium project
or somewhere for someone to look into if interested. (2) there is option to try "Appium
for Mac" to drive Safari on Mac. Consider it beta/prototype quality as well: https://github.com/appium/appium-for-mac/blob/master/examples/safari.py

If these workarounds don't meet your needs, consider yourself out of luck.

Reported by mangaroo on 2015-05-06 19:11:54

[lukeis]

Reported by jmleyba on 2015-05-06 19:13:31

[lukeis]

Best solution I found for to handle Selenium safari alert workaround is 

Inject this javascript into browser before alert will occur, and you will found alert
will automatically accepted.

((JavascriptExecutor)browser).executeScript("confirm = function(message){return true;};");

((JavascriptExecutor)browser).executeScript("alert = function(message){return true;};");

((JavascriptExecutor)browser).executeScript("prompt = function(message){return true;}");



for more information please visit

http://qa-robot.blogspot.in/2013/07/working-with-alerts-alert-handling-2.html

-Paras

Reported by paras.patidar@lmsin.com on 2015-05-14 10:01:21

[lukeis]

Reported by luke.semerau on 2015-09-17 18:15:22

• Labels added: Restrict-AddIssueComment-Commit