Selenium RC Per-Session Extension Javascript
Several people have asked if it is possible to specify user extension Javascript dynamically with the RC, as opposed to on the command line with the -userExtensions flag when starting up the server. It wasn’t possible before.
It should be now.
If you build from r2291 or greater from the RC trunk, you can play with it. Basically, the extension Javascript must be specified before the browser is launched, and stays in-play until the session is closed. A sample test has been checked in here:
This probably doesn’t work for proxy injection mode yet.
Happy extending!
Update
It appears too easy to encounter the “414 Request URI Too Large” issue. I’m looking into this.
Update
Looks like the 414 issue is related specifically to the Perl driver (see this Clearspace post); I noticed it when using Perl, but did not see the issue when running an equivalent test in Groovy:
import com.thoughtworks.selenium.*
class URILengthTest extends GroovyTestCase {
def selenium
@Override
void setUp() {
selenium = new DefaultSelenium('localhost',
4444, '*firefox',
'http://alistapart.com')
}
@Override
void tearDown() {
selenium.stop()
}
void testURILength() {
def extensionJs = new File(
'selenium-core/src/main/resources/core/scripts/ui-map-sample.js').text
selenium.setExtensionJs(extensionJs)
selenium.start()
selenium.open('http://alistapart.com')
selenium.click(
'ui=allPages::section(section=topics)')
selenium.waitForPageToLoad('5000')
}
}
Update
Unfortunately, the 414 issue also affects the Python and Ruby client drivers (I just tested and verified this). I’m not about to fix them right this moment, so it appears the you can only truly take advantage of the per-session extension feature (i.e. include extensions of arbitrary size) in Java and Groovy for now.
The good news is that this issue has already been reported, and JIRA tickets created (SRC-319 for Perl, SRC-321 for Python, SRC-322 for Ruby, and others for C# and PHP).
August 7th, 2009 at 00:21
Does UI-element have support with selenium grid ? I am not able to execute with GRID . however I was able to use UI-element with IDE with out any issues?
I used ‘selenium.setExtensionJs()’ method before starting browser even though, I got following error message
[java] 22:31:53.531 INFO – Got result: ERROR: Element ui=allPages::Productsolutions() not found on session 4c57c1826fb44e74b729fbe60afd2f45.
Any thing I missed ?
thanks,
Satyadev
September 22nd, 2009 at 08:15
Sorry to post the following here, but I could not send you a message from clearspace.openqa.org due to their technical problems.
I have a problem with extending Selenium with a new command which returns something – it fails with ‘this.waitForCondition is not a function’ exception.
Below are my settings:
1. selenium-server.jar – user-extensions.js:
Selenium.prototype.doReturnElement = function(element) {
return this.browserbot.findElement(element);
};
2. selenium-java-client-driver.jar – Selenium.java
…
void returnText (String text);
…
DefaultSelenium.java
…
public void returnElement(String element) {
commandProcessor.doCommand(“returnElement”, new String[] {element});
}
…
3. MyTest.java:
…
public void testValidElement() {
selenium.returnElement(“//a”);
}
public void testInvalidElement() {
selenium.returnElement(“invalid”);
}
…
When running the test, different exceptions are thrown:
1. In case of non-existing element:
com.thoughtworks.selenium.SeleniumException: ERROR: Element invalid not found
at com.thoughtworks.selenium.HttpCommandProcessor.throwAssertionFailureExceptionOrError(HttpCommandProcessor.java:97)
at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:91)
at com.thoughtworks.selenium.DefaultSelenium.returnElement(DefaultSelenium.java:743)
at MyTest.testInvalidElement(MyTest.java)
2. In case of existing element:
com.thoughtworks.selenium.SeleniumException: this.waitForCondition is not a function
at com.thoughtworks.selenium.HttpCommandProcessor.throwAssertionFailureExceptionOrError(HttpCommandProcessor.java:97)
at com.thoughtworks.selenium.HttpCommandProcessor.doCommand(HttpCommandProcessor.java:91)
at com.thoughtworks.selenium.DefaultSelenium.returnElement(DefaultSelenium.java:743)
at MyTest.testValidElement(MyTest.java)
The latter exception is also thrown when the doReturnElement simply returns a string.
Thank you very much in advance,
Irina
October 8th, 2009 at 23:10
@ikostenko: I believe the strange behavior you’re seeing is due to your new Selenium command not following the semantics for the different “types” of commands, i.e. “actions” and “accessors”. Actions are named starting with “do”, while accessors are named starting with “get”. You can see in selenium-commandhandlers.js that the two are registered differently (look for
_registerAllAccessorscompared to_registerAllActions).I think the return value of the command is used differently, depending on the type of command. Since you’re interested in actually returning a value (and not a condition closure or null), you probably want to use “getElement” instead of “doReturnElement”.
Hope it works out for you.
February 19th, 2010 at 08:50
Just a heads-up for anyone trying to use this SetExtensionJS() interface. You can’t use this to create a Selenium command like you can with user-extensions.js, because the code that registers command handlers is run before SetExtensionJS() injects your code.
August 19th, 2010 at 09:35
I’ve tried to extend the Selenium locators using the per-session extension script, and that also fails. I’ve posted a question about this on the selenium-users mailing list at http://groups.google.com/group/selenium-users/browse_thread/thread/4469b18f8909f2d
I’ll post back here when I get an answer on the list.
August 23rd, 2010 at 03:40
I worked out a solution, check out my blog at http://stuvel.eu/archive/131/extending-selenium-from-the-client-driver for more information.