search

ericmckean / webkitdriver

Automatically exported from code.google.com/p/webkitdriver
0 stars 0 forks source link

findElementById should use Document.getElementById #7

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
WebKitWebElement.java has the following code to find a given element by its ID: 

  public List<WebElement> findElementById(String id) {
    assertElementNotStale();
    return findElementByXPath(".//*[@id ='" + id +"']");
  }

WebCore::Document class has a convenient method called getElementById. 
findElementById should use that instead of resorting to xpath to improve 
performance.

Original issue reported on code.google.com by ba...@google.com on 5 Dec 2010 at 5:47

GoogleCodeExporter commented 9 years ago 
Please note that findElementsById have to use XPath anyways to return list of 
values, and first element returned by findElementById can differ from element 
returned by findElementById, if document have several elements with same id.

Original comment by viarheic...@google.com on 6 Dec 2010 at 11:00

GoogleCodeExporter commented 9 years ago 
I agree, the findElementsById should continue using xpath.

However I don't see a reason why findElementById should still use xpath.
It's one WebDriver element lookup call used most of the time, and it only
ever returns one Node. Converting it to use getElementById makes more sense
to me.

Why would the first element returned by findElementsById be different than
what getElementById would return?

- Baran

Original comment by ba...@google.com on 6 Dec 2010 at 12:42

GoogleCodeExporter commented 9 years ago 
I agree that using getElementById is more efficient, just point to probable 
inconsistency with pair function returning multiple values - if it uses 
different search engine, so element ordering can differ. Anyways, I do not 
think this can cause any problems in real-life usage scenarios.

Original comment by viarheic...@google.com on 6 Dec 2010 at 3:23