5.13. How to Automate Native Browser Dialogs, ActiveX, and more

Table of Contents

5.13.1. Automating native browser dialogs (login, certificates, etc.)
5.13.2. ActiveX

Squish is primarily designed to support the automation of operations on web pages' DOM, DHTML, and HTML elements. But to completely test a web application, it is often necessary to automate operations on other kinds of component, and also on dialogs—this section shows the techniques used to perform such testing.

5.13.1. Automating native browser dialogs (login, certificates, etc.)

Many web applications require a login using the browser's native authentication dialog, or the acceptance of certificates as part of the startup process. Squish makes it is possible to automate logins and the acceptance of certificates as described below.

5.13.1.1. Automating a native login

Squish provides a custom function that you can call from your test scripts to automate a login with the browser's native authentication dialog. The key to using it is to start the login process (typically by clicking a button or link), then wait for the login dialog to appear, and then enter the username and password. Here's an example snippet that shows how it might be done:

Python
clickLink(":Login_A")
waitFor("isBrowserDialogOpen()")
automateLogin(tester_username, tester_password)
JavaScript
clickLink(":Login_A");
waitFor("isBrowserDialogOpen()");
automateLogin(tester_username, tester_password);
Perl
clickLink(":Login_A");
waitFor("isBrowserDialogOpen()");
automateLogin($tester_username, $tester_password);
Ruby
clickLink(":Login_A")
waitFor("isBrowserDialogOpen()")
automateLogin(tester_username, tester_password)
Tcl
invoke clickLink ":Login_A"
invoke waitFor {invoke isBrowserDialogOpen}
invoke automateLogin $tester_username $tester_password

The snippet assumes that tester_username and tester_password are variables that hold the tester's username and password.

In some cases there is no such Login button or link, instead the login dialog is opened up automatically while the website starts to load. This use case needs a slightly different approach when this website is being loaded with the startBrowser function.

Squish ensures the website given to the startBrowser function is loaded before returning from it to the test script. While the browser shows the login dialog the loading of the website will be paused and not proceed until the dialog has received the proper login data. This is a problem since the automation of the login can only happen once the startBrowser function has finished and the following automateLogin invocation is being executed. So the test will eventually hang until startBrowser runs into its timeout and generate an error.

In order to make this usecase work nonetheless it is necessary to load an unprotected website first such that startBrowser can finish successfully. Once startBrowser is done you can use loadUrl to load a different website in the browser tab. The loadUrl function does not wait for the page to be fully loaded and thus returns immediately even if the website opens the login dialog. The following snippet shows a small example code that handles this scenario:

JavaScript
startBrowser("http://www.froglogic.com");
loadUrl(activeBrowserTab(), "http://secureweb.site");
waitFor("isBrowserDialogOpen()");
automateLogin(tester_username, tester_password);
Python
startBrowser("http://www.froglogic.com")
loadUrl(activeBrowserTab(), "http://secureweb.site")
waitFor("isBrowserDialogOpen()")
automateLogin(tester_username, tester_password)
Perl
startBrowser("http://www.froglogic.com");
loadUrl(activeBrowserTab(), "http://secureweb.site");
waitFor("isBrowserDialogOpen()");
automateLogin($tester_username, $tester_password);
Ruby
startBrowser("http://www.froglogic.com")
loadUrl(activeBrowserTab(), "http://secureweb.site")
waitFor(isBrowserDialogOpen)
automateLogin(tester_username, tester_password)
Tcl
invoke startBrowser "http://www.froglogic.com"
invoke loadUrl [invoke activeBrowserTab] "http://secureweb.site"
invoke waitFor {invoke isBrowserDialogOpen}
invoke automateLogin $tester_username $tester_password

Squish's automateLogin function automates the native browser authentication dialog for any of Squish's supported browsers, so you don't have to make any allowances for browser differences yourself.

[Note]macOS-specific

On macOS you must turn on Universal Access in the System Preferences when you use the automateLogin function.

5.13.1.2. Automating accepting certificates

Automating the acceptance of a certificate depends on which web browser is used. This section explains what needs to be done for each of Squish's supported web browsers to automate this process.

5.13.1.2.1. Internet Explorer 8 and later

The only step necessary to automate accepting a certificate when running a test in Internet Explorer is to accept it once, permanently. This must be done manually. After this, Squish will tell Internet Explorer to use the accepted certificate on each test run, and no further manual intervention is required.

5.13.1.2.2. Mozilla Firefox

To accept a certificate in Firefox, you must add some code to your script that will automate the browser dialogs for accepting the certificate. In addition it is necessary to work around an issue in Firefox would make the test case hang. To do this, first a temporary site must be loaded, and then the real site can be loaded.

Here is an example that shows how to automate connecting to an HTTPS site and accepting the certificate.

Python
# Workaround: Load a temporary page first
startBrowser("http://www.froglogic.com")
# Now load the real page
loadUrl(activeBrowserTab(), "https://the.real.site.you.want.to.load")
if Browser.type() == Browser.Firefox:
    # Accept the certificate
    waitFor("isBrowserDialogOpen()")
    nativeType("<Return>")
    snooze(1)
    # Accept the second certificate dialog
    nativeType("<Left>")
    nativeType("<Return>")
    waitFor("not isBrowserDialogOpen()")
    rehook()
JavaScript
// Workaround: Load a temporary page first
startBrowser("http://www.froglogic.com");
// Now load the real page
loadUrl(activeBrowserTab(), "https://the.real.site.you.want.to.load");
if (Browser.type() == Browser.Firefox) {
    // Accept the certificate
    waitFor("isBrowserDialogOpen()");
    nativeType("<Return>");
    snooze(1);
    // Accept the second certificate dialog
    nativeType("<Left>");
    nativeType("<Return>");
    waitFor("!isBrowserDialogOpen()");
    rehook();
}
Perl
# Workaround: Load a temporary page first
startBrowser("http://www.froglogic.com");
# Now load the real page
loadUrl(activeBrowserTab(), "https://the.real.site.you.want.to.load");
if (Browser.type() == Browser.Firefox) {
    # Accept the certificate
    waitFor("isBrowserDialogOpen()");
    nativeType("<Return>");
    snooze(1);
    # Accept the second certificate dialog
    nativeType("<Left>");
    nativeType("<Return>");
    waitFor("!isBrowserDialogOpen()");
    rehook();
}
Ruby
# Workaround: Load a temporary page first
startBrowser("http://www.froglogic.com")
# Now load the real page
loadUrl(activeBrowserTab(), "https://the.real.site.you.want.to.load")
if Browser.type() == Browser.Firefox
    # Accept the certificate
    waitFor("isBrowserDialogOpen()")
    nativeType("<Return>")
    snooze(1)
    # Accept the second certificate dialog
    nativeType("<Left>")
    nativeType("<Return>")
    waitFor("!isBrowserDialogOpen()")
    rehook()
end
Tcl
# Workaround: Load a temporary page first
invoke startBrowser "http://www.froglogic.com"
# Now load the real page
invoke loadUrl [invoke activeBrowserTab] "https://the.real.site.you.want.to.load"
if {[[invoke Browser type] == Browser.Firefox]} {
    # Accept the certificate
    waitFor {isBrowserDialogOpen}
    invoke nativeType "<Return>"
    snooze 1
    # Accept the second certificate dialog
    invoke nativeType "<Left>"
    invoke nativeType "<Return>"
    waitFor {expr ! [isBrowserDialogOpen]}
    rehook
}

Loading the temporary page is just an unfortunate—but hardly noticeable—necessity. Once the page has loaded, Firefox uses two dialogs to complete the acceptance of a certificate, so we must interact with both of them to complete the acceptance. We use the nativeType function to simulate the keyboard interaction, where normally we'd use the type function. Also, after interacting with the dialogs we must call the rehook function to make Squish do some reloading and reinitialization to account for the fact that the certificate has now been accepted and that as a result, the web page is in a different state.

5.13.1.2.3. Google Chrome

There is no configuraton or test script code needed with Google Chrome. Squish starts Chrome such that it will allow access to websites using any kind of ssl-certificate, such that no acceptance has to be done.

5.13.1.2.4. Safari

The only step necessary to automate accepting a certificate when running a test in Safari is to accept it once, permanently. This must be done manually: First, open the page with the certificate in Safari, then choose to view the details of the certificate in the sheet that pops up, then check the checkbox that tells Safari to always trust the certificate on reconnects. After this, Squish will tell Safari to use the accepted certificate on each test run, and no further manual intervention is required.

5.13.2. ActiveX

Squish supports automating interactions and testing non-HTML/DOM elements, that is, native objects, which are embedded in a web page. This is done at a fairly abstract level, which means that mouse and text input can be recorded and replayed. In addition it is possible to inspect embedded native objects with the Spy tool and to insert verifications for these native objects. All of a native object's public properties can be accessed in test scripts.

[Note]Windows and Internet Explorer-specific: ActiveX

ActiveX is a Windows-specific technology, so there is no support for it on other platforms. Squish's Qt edition supports ActiveX, and so does Squish's Web edition —but in the latter case, only in Internet Explorer.