I recently attempted to use selenium RC's GetAttribute method but immediately ran into a challenge. I tried to execute a very simple selenium.GetAttribute("//a/@href")
but the code threw a SeleniumException with the message "ERROR: Could not find element attribute: //a/@href".
By substituting selenium.GetText("//a[@href]")
in place of the GetAttribute call, I confirmed that an element was definitely present, as this statement properly returned the text of the link.
I then tried:
- pointing to a different web page with a different protocol (file:/// vs http://) -- same problem.
- using a different xpath locator pointing to a different attribute -- same problem.
- using a DOM locator
selenium.GetAttribute("document.getElementsByTagName('a')[0].getAttribute('href')")
-- same problem; slightly different error message (and the error message is missing the final parenthesis): "ERROR: Element document.getElementsByTagName('a')[0].getAttribute('href' not found". Note that this exact expression works correctly in Firebug's console. - using absolute instead of relative xpath addressing, with
selenium.GetText("xpath=/html/body/a[@href]")
to confirm the existence and thenselenium.GetAttribute("xpath=/html/body/a/@href")
to get the attribute -- and it worked!
While the manual clearly states that relative xpath locators do not need an explicit locator type (i.e. the "xpath=" prefix) it is silent about absolute xpath locators; I interpret from this that the prefix is required. But out of curiousity, I went back to my relative expression and added the explicit prefix--changing selenium.GetAttribute("//a/@href")
to selenium.GetAttribute("xpath=//a/@href")
-- and this also worked!
Finally, my experiments with the very handy Find button in Selenium IDE show that it does fine with elements but fails with attributes. I can understand that it is not meaningful to highlight an attribute since attributes are not visible page elements, but why not highlight the element containing the attribute, and make it in a different color? Perhaps not a trivial task...
My questions:
I distilled the results of the above experiments down to these questions; this is the whole purpose of my posting here! Each of these seems like a bug to me but let me know if you think my usage is incorrect or there is a workaround:
- Why does GetAttribute with an XPath locator type uniquely require an explicit locator type when other methods (e.g. GetText) do not?
- Why did the DOM locator fail with a 'not found' error? (The manual also clearly states that DOM locators do not require an explicit locator type prefix, but I nevertheless tried adding "dom=" as a prefix on the DOM test; it still failed.)
- Why does Selenium IDE not fail more gracefully when attempting to highlight (Find) an attribute? With the same
"xpath=//a/@href"
locator, pressing the Find button yields this ugly message: "[error] locator not found: xpath=//a/@href, error = [Exception... "Could not convert JavaScript argument arg 0 [inIFlasher.scrollElementIntoView]" nsresult: "0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS)" location: "JS frame :: chrome://selenium-ide/content/selenium-runner.js :: showElement :: line 386" data: no]"
Your input is also requested for the following: The pattern I wanted for each test here was (A) GetText(locator-for-element-with-attribute) to confirm the presence of the element then (B) GetAttribute(locator-for-attribute-itself). Of the 6 slots in the table below I solved 3 of them successfully as just detailed, and a 4th seems to be a bug. Are there solutions for the remaining two slots?
Type GetText GetAttribute XPath //a[@href] xpath=//a/@href CSS css=a[href] ?? DOM ?? document.getElementsByTagName('a')[0].getAttribute('href')
(Details: Selenium RC version 1.0.3, Browser: Firefox 3.6.13, My target code in C#)