Dan Fabulich integrated a new Safari launcher in Selenium Remote Control. This is big news for Selenium and Selenium Grid users since this launcher provides a very simple way to bypass the same origin policy and run privileged JavaScript in Safari.
If you are already familiar with Selenium Remote Control, this essentially means that for Safari you get a mode that is very much like the *chrome mode for Firefox.
So, why is this such great news?
To automate your browsing session – opening a new Window, clicking on a button, collecting the content of an HTML element – Selenium is loading a JavaScript test runner in your browser under the hood. This JavaScript test runner is the component that actually drives your web application within the browser itself. This statement holds true whether you are authoring your tests in HTML, Java, Ruby, Python or Erlang, and whether you are running your tests using Selenium IDE, Selenium Remote Control or Selenium Grid.
This implies that the JavaScript test runner must load itself – from your local machine where Selenium is installed – and then load pages from the web application under test which are usually hosted on another machine (say ph7spot.com).
Fortunately for our day-to-day web browsing experience but unfortunately for Selenium, there is a far-reaching security restriction in JavaScript that prevents a script loaded from one origin to read or modify the properties of windows and documents coming from a different origin1. This restriction is usually referred to as the same origin policy. Its intent is to prevent a malicious script from compromising the confidentiality or integrity of another web page. Without this protection, a rogue third-party script would have a straight shot at impersonating the current user (e.g. issuing HTTP request in the context of the current web session) or impersonating a trusted website (e.g. stealing user credentials and/or sensitive information).
The same origin policy, therefore, also gets in the way of Selenium automation: Selenium must load the JavaScript test runner from localhost as well as the web application under test from another domain (say ph7spot.com). This is why, in a lot of ways, Selenium Remote Control is all about launching browsers and finding creative solutions to bypass the same origin policy. Most of these creative solutions revolve around 2 strategies:
Pretending the web pages of the application under test come from localhost, by setting the Remote Control as a web proxy for the browser. This means that the Remote Control must change your browser or system proxy settings before launching the browser, and restore them once you are done with the session.
Finding a way to run JavaScript in privileged mode which does not enforce the same origin policy. Obviously, there is no guarantee that such a mode exists and can be reached for every browser. Besides, even when such a mode does exists, the way to enter this privileged mode is always browser-specific and discovering it typically takes some time and entails a good understanding of the browser’s underlying architecture. For instance, Selenium uses the Chrome and HTA technologies to enter privileged mode on Firefox and Internet Explorer (respectively).
The great advantage of going with the proxy strategy is that it is guaranteed to work from day one with any browser, even if you do not discover any secret way to enter a super privileged mode. Its main drawback, however, is that the proxy settings have to be saved, changed and restored at the beginning and end of every Selenium Session. For Selenium Grid, which distributes tests among multiple Remote Controls, the proxy strategy quickly becomes a real problem for browsers (namely Internet Explorer and Safari) whose proxy settings can only be changed globally, at the operating system level. Multiple Remote Controls running on the same machine asynchronously compete to change the global system proxy settings… a sure recipe for mysterious failures and an unstable infrastructure!!!
This is why as far as Selenium Grid is concerned, the privileged mode strategy – which does not affect any web proxy settings – is the way to go. It is conducive to a setup with no interference between system settings, Remote Controls, browsers and Selenium Sessions.
This is why I am so excited about Dan Fabulich’s privileged mode for Safari. It means that Selenium Grid gets extremely efficient Safari support, totally on par with its Firefox support. As it turns out, in a Selenium Grid context, running your web acceptance test suite on Safari is even typically faster than running it on Firefox. Let me tease you with a screenshot of Selenium Grid running 18 Safari browsers in parallel on my MacBook Pro:
Another interesting thing about the new Safari privileged mode is that it actually works in a very simple way. Dan discovered that in Safari, file URLs are not restricted by the same-origin policy. So the solution is as simple as loading the Selenium Core JavaScript test runner directly from the file system!
The new Safari privileged mode is the default mode in Selenium RC 1.0 beta 2 and Selenium Grid 1.0.3. To access the new privileged mode, just use the good old *safari browser string when you start the Selenium session. There is one gotcha though: If, just after Safari launches, your browser seems to be hanging in limbo in a state similar to the screen shot below, make sure that Safari is not configured to block popup windows.
Moving forward, we need to automate this setting change, but for now please manually check that the “Block Pop-Up Windows” option in the Safari main menu is not enabled before launching your tests.
Hopefully you are now as excited about Safari and Selenium Grid as I am. So happy hacking, and have fun with the Grid!
To be precise, the term origin is defined in context as the combination of protocol, domain name and port number in the URL serving the document. So, for instance, http://ph7spot.com and http://seleniumhq.org are considered to have different origins because they have different domain names. In the same way http://ph7spot.com and https://ph7spot.com are also considered to have different origins as they use different protocols (http and https).
It is also worth clarifying that the same origin restrictions do not apply to all interactions. For instance, it’s fairly common for a web page to include images, stylesheets, and scripts from other domains.
Previous Topic
