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 then `selenium.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:

1. Why does GetAttribute with an XPath locator type uniquely require an *explicit* locator type when other methods (e.g. GetText) do not?
2. 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.)
3. 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#)