Adding getParent() method to WebElement

[Will Roden]

I added a method to WebElement to get its WebDriver parent. This lets
me more easily pass WebElements into wrappers without also having to
pass their driver objects. It is working out for me so far, but I am
also concerned that I am going to regret this down the line. getParent
() seems like such an obvious getter for WebElement, that I suspect it
was left out for a good reason. Is there a good reason that I should
avoid doing this?

[Simon Stewart]

Apologies for the brevity of this email, I'm about to call it a day :)

It was left out because webdriver isn't a tool for doing random walks
of a webpage and because there are already mechanisms to get hold of
the parent element that don't add additional methods to one of the
core interfaces. As you've noticed, it's trivial to implement this
method in your own code if it's really necessary for your application.

Regards,

Simon

> --
> You received this message because you are subscribed to the Google Groups "webdriver" group.
> To post to this group, send email to webd...@googlegroups.com.
> To unsubscribe from this group, send email to webdriver+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webdriver?hl=en.
>
>
>
>

[Will Roden]

Simon,

Thanks for your quick reply. I am all about leaving the core
interfaces as they are and not modifying webdriver's source code. I
suspect you misread my previous post as wanting to get the
WebElement's DOM parent (a common query for this list), but I am
actually after its WebDriver parent. I want to be able to access the
WebDriver so I can execute javascript on the WebElement.

I don't cherish the idea of patching every webdriver release with my
own customizations, so if there is another path to the WebDriver
parent, I will certainly take it.

-Will

[Tomás Pollak]

Hi,

this was discussed here some time ago:
http://groups.google.com/group/webdriver/browse_thread/thread/46182ea22d516238/

Or, more simply:

WebElement parent = element.findElement(By.xpath(".."));

Cheers,
Tomás

[Simon Stewart]

Ah. Thank you for your patience: I did misread your post. Getting hold
of the driver that created a webelement is a far more useful thing to
add :) I'll have a think about it, but on the surface, I can't see why
it couldn't be added. Anyone?

Regards,

Simon

[Eran M.]

I have no reason why not to add it, but I am curious about the motive behind it -

Will, can you provide some details about which Javascript you execute in relation to the WebElement?

The reason I'm asking is that I've had a need to execute JS on elements in order to find sub-elements - something like WebElement.findElementByJavascript(...). If the need is similar, perhaps a solution for both our problems can be created.

Eran 

2010/1/6 Simon Stewart <simon.m...@gmail.com>

[Daniel Wagner-Hall]

My one concern would be context - if you're dumping elements
somewhere, then using the WebDriver instance to do other things, then
calling WebElement.getParent(), I would expect the WebDriver to be in
a state where it could actually act on the element, whereas in reality
the element would likely be stale. All of the same effects can be
achieved by actually having the WebDriver instance alongside the
WebElement, but getParent() seems to imply longer term stability,
which doesn't exist.

[Will Roden]

Your misreading the post was helpful in determining that getParent is
the wrong name for that method. I'll call it getDriver instead to
avoid confusion for the next poor sap who has to maintain my code.

[Will Roden]

Eran,

This would be useful for finding sub-elements with js when you don't
already have the driver, but that isn't my particular need right now.
Sometimes webdriver and jQuery have different opinions about whether a
checkbox is checked, so I am trying to sniff out these instances using
the function below which is part of a class that wraps form fields.

public Boolean getJQueryValue() {
WebDriver driver = webElement.getDriver(); //Changed getParent()
to getDriver() to avoid confusion
JavascriptExecutor js = (JavascriptExecutor) driver;
return (Boolean) js.executeScript("return jQuery(arguments[0]).attr
('checked')", getInputElement());
}

-Will

On Jan 6, 5:57 am, "Eran M." <eran....@gmail.com> wrote:
> I have no reason why not to add it, but I am curious about the motive behind
> it -
> Will, can you provide some details about which Javascript you execute in
> relation to the WebElement?
>
> The reason I'm asking is that I've had a need to execute JS on elements in
> order to find sub-elements - something like
> WebElement.findElementByJavascript(...). If the need is similar, perhaps a
> solution for both our problems can be created.
>
> Eran
>

> 2010/1/6 Simon Stewart <simon.m.stew...@gmail.com>

>
>
>
> > Ah. Thank you for your patience: I did misread your post. Getting hold
> > of the driver that created a webelement is a far more useful thing to
> > add :) I'll have a think about it, but on the surface, I can't see why
> > it couldn't be added. Anyone?
>
> > Regards,
>
> > Simon
>

> > webdriver+...@googlegroups.com<webdriver%2Bunsubscribe@googlegroups .com>

> > .
> > >> > For more options, visit this group athttp://
> > groups.google.com/group/webdriver?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > "webdriver" group.
> > > To post to this group, send email to webd...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > webdriver+...@googlegroups.com<webdriver%2Bunsubscribe@googlegroups .com>

> > .
> > > For more options, visit this group at
> >http://groups.google.com/group/webdriver?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "webdriver" group.
> > To post to this group, send email to webd...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > webdriver+...@googlegroups.com<webdriver%2Bunsubscribe@googlegroups .com>

[Simon Stewart]

We already have a "WrapsElement" interface. Sounds like we could also
have a "WrapsDriver" one.

Simon

[QA_manager]

I think everyone misread this, so I agree that renaming the method is
a good plan.

[Will Roden]

Daniel,

Thanks for your feedback. I had not considered the stale-element
scenario because my intended use of getDriver (formerly getParent)
doesn't do anything that would make the element stale between when I
pass it to the wrapper and when I access getDriver(). Do you think
that if the element is stale, getDriver() should throw
StaleElementReferenceException instead of returning the parent driver?

-Will

On Jan 6, 7:11 am, Daniel Wagner-Hall <dawag...@gmail.com> wrote:
> My one concern would be context - if you're dumping elements
> somewhere, then using the WebDriver instance to do other things, then
> calling WebElement.getParent(), I would expect the WebDriver to be in
> a state where it could actually act on the element, whereas in reality
> the element would likely be stale.  All of the same effects can be
> achieved by actually having the WebDriver instance alongside the
> WebElement, but getParent() seems to imply longer term stability,
> which doesn't exist.
>
>
>
> On Wed, Jan 6, 2010 at 9:00 AM, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> > Ah. Thank you for your patience: I did misread your post. Getting hold
> > of the driver that created a webelement is a far more useful thing to
> > add :) I'll have a think about it, but on the surface, I can't see why
> > it couldn't be added. Anyone?
>
> > Regards,
>
> > Simon
>

[Simon Stewart]

The naive implementation wouldn't throw an exception, which may lead
to some wonky results unless the next method call attempts to use the
stale element too.

Simon

[Jason Leyba]

Will,

The tricky thing is the language bindings (java, python, etc.) don't
track whether a WebElement is stale. The actual driver makes this
check before executing a command on an element. With respect to your
isSelected() issue, which browser are you getting this problem on?

-- Jason

[Will Roden]

The isSelected() issue happened with the firefox driver, but I
couldn't recreate it when I tried a few minutes ago. I suspect the
fix was in the svn up I did before adding getDriver().

-Will