|
7 Replies
Last post:
Jan 7, 2009 11:27 AM by
Paul Grandjean
Paul,
Yet more good questions ... you're forcing me to go digging for the answers myself, which is good. 
1) I don't believe HTA and chrome modes involve a proxy between the browser and AUT. They are able to circumvent the same origin policy because they are running with elevated privileges. HTA, or "HTML Application", is really an HTML file that is opened locally, and as such can access the filesystem and basically act like a desktop application, thus escaping the browser sandbox ... and the same origin policy. Chrome is an elevated privilege mode for Firefox that is accessed via "chrome URL's", i.e. URL's that start with "chrome://" . Firefox plugins, for example, are accessed via chrome URL's, and are able to use the Firefox API's for accessing / modifying the filesystem and again basically acting like a full fledged application. With these two privileged modes, it's not necessary to have a proxy.
2) If you run the Selenium server with an invalid argument, it will print out a help message. This will give you an idea of the ways in which proxy injection can be useful:
...
-proxyInjectionMode: puts you into proxy injection mode, a mode
where the selenium server acts as a proxy server for all content
going to the test application. Under this mode, multiple domains
can be visited, and the following additional flags are supported:
-dontInjectRegex <regex>: an optional regular expression that
proxy injection mode can use to know when to bypss injection
-userJsInjection <file>: specifies a JavaScript file which will
then be injected into all pages
-userContentTransformation <regex> <replacement>: a regular
expression which is matched against all test HTML content; the
second is a string which will replace matches. These flags can
be used any number of times. A simple example of how this could
be useful: if you add "-userContentTransformation https http"
then all "https" strings in the HTML of the test application will
be changed to be "http".
...
Apart from rewriting HTTPS URL's as HTTP, another example use of for proxy injection is capture javascript errors that happen on the page, by redefining window.onerror . Normally, you are not able to catch any javascript errors that happen on the page during page load. However, because PI mode allows you to inject script content before the page content, the redefinition of onerror will happen in time to catch the errors.
One note about the -userJsInjection flag - the entire content of the file you specify will be included before the <html> element on the page, and will not be automatically placed in a <script> block. Thus, the content of the injected file should probably be something like:
<script>
// my customizations
window.error = function() { return true; }
...
</script>
And also remember that when using PI mode, you need to specify a PI browser, i.e. *piiexplore .
3) PI mode has been consistently labeled as "experimental" in the documentation. I'm not sure of the extent of its usage. It was broken in Subversion for a while and I didn't personally encounter a ton of complaints (but that doesn't mean anything!) Some JIRA tickets indicate a desire to make PI mode the default mode, but I'm not sure if that's still the intention. It should be working in the latest snapshot.
Haw-Bin
