Up to Blog Posts in Selenium
Previous Next

Selenium

Currently Being Moderated
Haw-Bin Chai

Selenium RC Beta-2 Goodies and Gotchas

Posted by Haw-Bin Chai on Jan 13, 2009 12:00:26 PM

The beta-2 release of Selenium RC contains some significant changes you should be aware of. I'll describe some of those here.

 

Most notably, the default behaviors of the *iexplore and *firefox browser launchers have changed, to provide a better "first experience" for new users. *iexplore is now equivalent to *iehta . A new mode name has been added, *iexploreproxy, which is equivalent to the old *iexplore. Similarly, *firefox is now equivalent to *chrome . The *firefoxproxy mode is equivalent to the old *firefox.

 

To summarize:

 

LAUNCHER NAME          DESCRIPTION                    CROSS-DOMAIN

*iexplore, *iehta  =>  Internet Explorer in HTA mode  YES
*iexploreproxy     =>  Internet Explorer normal       NO
*firefox, *chrome  =>  Firefox in Chrome mode         YES
*firefoxproxy      =>  Firefox normal                 NO

 

Another significant change is the default to multi-window mode. Previously, you could tell the Selenium server to run in multi-window mode by providing the -multiWindow switch when starting it up. Now, multi-window is the default. This too provides a better first experience for users of framed applications. To return to previous behavior, you now specify the oppositve -singleWindow switch.

 

Selenium Core beta-1, included in RC beta-2, includes a couple of new features you may find useful.

 

First, we've started using a new, faster javascript XPath library for browsers that don't have native XPath, like IE. You can select this library in your test with the useXpathLibrary Selenium command. To select the new library, specify javascript-xpath as the target of the command. To select the original library, specify either ajaxslt , or simply default .

 

Secondly, I'm personally pleased to announce that UI-Element has been merged in. UI-Element is a feature allowing you to write a map file in javascript which can provide a layer of abstraction between the label used to identify elements on the page, and the actual Selenium locator that is used to locate the element. In practice, this makes it much easier to cope with a continually changing user interface - instead of updating all tests when an interface element changes, you simply update the map. More documentation on UI-Element can be found here: http://svn.openqa.org/fisheye/browse/~raw,r=2181/selenium/trunk/src/main/resources/core/scripts/ui-doc.html.

 

Enjoy these new features of the beta! And if you have questions, post to the forum, or join us on IRC:

 

server: irc.freenode.net

room: #selenium



Jan 19, 2009 2:47 PM Gina Gina    says:
Hi..
What about with the launcher of Safari? With the beta-2 release of Selenium RC, I can not run my test cases with Safari.
And how can I configure the plug-in of Maven in the POM of my application to run the test cases in singleWindow?
Jan 19, 2009 4:15 PM Gina Gina    says:

I can set the Maven plug-in to start the Selenium server in singleWindow mode, and I noticed that the Safari browser can not start in multiWindow mode, but with the singleWindow mode one of my test cases that needs select a frame fails. With IEHTA and singleWindow mode also has several fails.
Feb 3, 2009 12:49 PM dumbQAmonkey dumbQAmonkey    says:

I wanted to share some of my experiences with 1.0 beta 2.  I currently have a fairly extensive test harness that I’ve been using for some time with the Java Client Driver:  version INFO - v0.9.2 [2006], with Core v0.8.3 [1879].  It works flawlessly on IE.

 

I just dropped in the 1.0 beta 2 jars for some testing:  version INFO - v1.0-beta-2 [2571], with Core v1.0-beta-2 [2330]

 

Without too much effort (thanks to Haw-Bin Chai’s Goodies and Gotchas), I was able to get the entire test harness to run flawlessly on 1.0 Beta 2 and IE7.  However, I did run into the following issues that I believe should be addressed with either bug fixes or documentation. 

 

  1. The getDefaultPort() method seems to have been removed.  I was able to work around this by simply hard-coding the port number.

 

Here’s what may be some specific IE7 problems.

 

  1. When trying to run the new “javascript-xpath” library (on IE7), every xpath query seems to fail with a “invalid xpath:” error.  I do not know a thing about this new library, but the “javascript” and “ajaxslt” libraries both seemed to work just fine.
  2. I saw the multiWindow mode is now the default mode, however, there’s seems to be a huge performance impact vs singleWindow in IE7.  I have a very basic test that runs in 1 min 19 secs in singleWindow mode vs 3 mins 20 secs in multiWindow mode.  Multiply that by the whole test harness and you are talking about hours of difference.
  3. Also the multiWindow mode seems to resize the windows on my test boxes so that the Selenium window takes about 80% of the screen and the application being tested takes about 20% of the screen, so you basically can’t see the app being tested.  I didn’t see a way to adjust this.  Regardless, issues #3 and #4 are resolved for me by switching to singleWindow mode.

 

I have never been able to run Firefox3 with Selenium before, which I can do now… hooray!  Most of the test harness ran right off the bat.  I did run into these issues:

 

  1. Firefox3 seems to consistently lock up for me on about the second page request using the default chrome mode.  I see errors such as:
    • Error: Permission denied to set property Window.name
    • Error: Permission denied to get property Window.document
    • Error: foo.form is undefined

Switching it to firefoxproxy seems to correct the lockup issues.

  1. In Firefox3, if I try and get the type attribute as seen below for a Select element, I get the following error:

DefaultSelenium.getAttribute (“//*[@id='foo']@type”)

 

 

ERROR: Could not find element attribute: //*[@id='organizationalUnit']@type

at com.thoughtworks.selenium.HttpCommandProcessor.throwAssertionFailureExceptionOrError (HttpCommandProcessor.java:97)

at com.thoughtworks.selenium.HttpCommandProcessor.doCommand (HttpCommandProcessor.java:91)

at com.thoughtworks.selenium.HttpCommandProcessor.getString (HttpCommandProcessor.java:262)

 

I would expect it to return the value “select-one” as it does in IE.

  1. I also run into the same problems as Issue #6 trying to get the type attribute for a textarea.  I would expect it to return the value “textarea” as it does in IE.
  2. On Firefox3, I could not get the following xpath query to work:  td[contains(text(),'foo')].  If I changed it to td[contains(text(),'')] it would return all the cells regardless of the text.  It worked fine on IE.  Is there another way to read the text from a cell in Firefox?  I was able to work around it by using the getTable() method to iterate through the table one cell at a time.  It works, but a bit inefficient.

 

I hope someone finds this useful, and if you have workarounds for Issues #6 and #7 I would like to hear them.
Feb 3, 2009 2:44 PM khelenek khelenek    says:

When you run java -jar selenium-server.jar and use the *chrome vs the *firefox option, you will get different URL's.

 

*firefox
chrome://src/content/TestRunner.html?auto=true&multiWindow=false&defaultLogLevel=info&baseUrl=http%3A%2F%2Fwww.amazon.com%2F/selenium-server/tests/&resultsUrl=http://localhost:4444/selenium-server/postResults&test=http%3A%2F%2Fwww.amazon.com%2Fselenium-server%2Ftests%2FTestSuite.html

 

*chrome
chrome://src/content/TestRunner.html?auto=true&multiWindow=false&defaultLogLevel=info&baseUrl=http%3A%2F%2Fwww.amazon.com%2F/selenium-server/tests/&resultsUrl=http://localhost:4444/selenium-server/postResults&test=http%3A%2F%2Flocalhost%3A4444%2Fselenium-server%2Ftests%2FTestSuite.html

 

Same thing with *iexplore and *iehta.  They are not actually the same, *chrome and *iehta work, but *iexplore and *firefox do not, because they have neither bypassed the security restrictions or used a proxy to fake out the test suite url.
Feb 5, 2009 3:53 AM Paul Grandjean Paul Grandjean    says in response to Gina:

Haw-Bin, these sound like excellent improvements.  I'm looking forward to using them.

 

I'm unlikely to get time to be an 'early-adopter' for you.  But I am copying the link to your note over to our documentation team thread so we make sure we add this to the docs.

 

Paul
Feb 6, 2009 3:48 AM miggs miggs    says in response to Paul Grandjean:

Is beta2 also working on a MAC?
Feb 6, 2009 4:52 AM Nicolas Kyriazopoulos-Panagiotopoulos Nicolas Kyriazopoulos-Panagiotopoulos    says in response to khelenek:

Yes, this should be made clearer, I spent a lot of time trying to undertand why my htmlSuites didn't working while classic C# RC did.
Feb 6, 2009 5:04 AM Nicolas Kyriazopoulos-Panagiotopoulos Nicolas Kyriazopoulos-Panagiotopoulos    says in response to dumbQAmonkey:

I had some errors which were more serious: I haven't managed to make the new version work on IE6 while the previous one worked (which is exactly the opposite of FF3). I use iehta, and I get the following messages:

11:43:59.846 DEBUG [11] org.openqa.selenium.server.browserlaunchers.AsyncExecute - Execute:Java13CommandLauncher: Executing 'C:\WINDOWS\system32\mshta.exe' with arguments:
'C:\DOCUME~1\selenium\LOCALS~1\Temp\customProfileDirdf5439fba4a248679dfed9fe363c1d1f\core\RemoteRunner.hta'
'sessionId=df5439fba4a248679dfed9fe363c1d1f&multiWindow=true&baseUrl=http%3A%2F%2F<oursitehere>&debugMode=false&driverUrl=http://localhost:4444/selenium-server/driver/&baseUrl=http://localhost:4444/selenium-server/'

 

The ' characters around the executable and arguments are
not part of the command.
11:44:00.858 DEBUG [11] org.openqa.selenium.server.browserlaunchers.AsyncExecute - spawned process java.lang.ProcessImpl@1b383e9
11:44:00.858 DEBUG [11] org.openqa.selenium.server.FrameGroupCommandQueueSet - waiting for window 'null' local frame 'null' for 1800 more secs
11:44:00.858 DEBUG [11] org.openqa.selenium.server.FrameGroupCommandQueueSet - waiting for condition for 1000 more ms

 

and it is waiting for ages here, of course...

The iexplore process seems to end very fast, and the mshta stays inert, doing nothing.

The same site IS working through -htmlSuite (command line execution).

 

On the other hand, the logs for -htmlSuite are not the same:

11:57:54.470 DEBUG [10] org.openqa.selenium.server.browserlaunchers.AsyncExecute - Execute:Java13CommandLauncher: Executing 'C:\WINDOWS\system32\mshta.exe' with arguments:
'C:\DOCUME~1\selenium\LOCALS~1\Temp\customProfileDir872918\core\TestRunner.hta'
'auto=true&multiWindow=true&defaultLogLevel=info&baseUrl=http%3A%2F%2F<ourSite>/selenium-server/tests/&resultsUrl=http://localhost:4444/selenium-server/postResults&test=http%3A%2F%2Flocalhost%3A4444%2Fselenium-server%2Ftests%2FTestSuite2.html&baseUrl=http://localhost:4444/selenium-server/'

 

The ' characters around the executable and arguments are
not part of the command.
11:57:55.471 DEBUG [10] org.openqa.selenium.server.browserlaunchers.AsyncExecute - spawned process java.lang.ProcessImpl@b8df17
11:57:58.776 DEBUG [11] org.mortbay.http.HttpConnection - new HttpConnection: Socket[addr=/127.0.0.1,port=4063,localport=4444]
11:57:58.836 DEBUG [11] org.mortbay.http.HttpConnection - REQUEST from SocketListener0@0.0.0.0:4444:
GET http://localhost:4444/selenium-server/tests/TestSuite2.html?thisIsChrome=false&thisIsHTA=true HTTP/1.0

...
Feb 9, 2009 4:14 AM Nicolas Kyriazopoulos-Panagiotopoulos Nicolas Kyriazopoulos-Panagiotopoulos    says in response to Nicolas Kyriazopoulos-Panagiotopoulos:

Should I make a separate thread for my problem?
Feb 11, 2009 6:49 AM Nicolas Kyriazopoulos-Panagiotopoulos Nicolas Kyriazopoulos-Panagiotopoulos    says in response to Nicolas Kyriazopoulos-Panagiotopoulos:

Is anybody reading this?
Feb 17, 2009 10:33 AM Santiago Suarez Ordoñez Santiago Suarez Ordoñez    says in response to Nicolas Kyriazopoulos-Panagiotopoulos:

Yes, I think you should...                   

May 14, 2009 9:37 AM Mark Lehky Mark Lehky    says in response to dumbQAmonkey:

dumbQAmonkey:

I also ran into your problem with "javascript-xpath". There is a Jira SRC-595 that apparently fixes this. Also, I think your solution of using just "javascipt" is not a good one - I think that this is a typo in the docs (see same Jira); if you try useXpathLibarry("crap") it runs as well - I suspect it deaults to the old "ajaxslt"

Mark.

 

update: I was wrong: using useXpathLibarry("javascript") uses "Cybozu Labs' faster library", and using useXpathLibarry("crap") makes no change -> uses the last selected.

Actions

Popular Blog Posts