Object no longer attached to the DOM error on doing a exists call

[Alastair Montgomery]

Hi,

I am experiencing an intermittent issue when doing the following call in watir-webdriver;

browser.div(:class => "blockUI").exists?

Sometimes it throws this exception;

Selenium::WebDriver::Error::ObsoleteElementError: Element is no longer attached to the DOM

Surely instead of throwing this the call should be returning false?

[Jari Bakken]

Yes, it shouldn't be throwing. Looking into it.

[Alastair Montgomery]

Thanks, please keep me updated of anything you find :)

[Alastair Montgomery]

Just reran my test suite this morning there were 9 errors all reporting the same error.

If it helps I am checking for a jQuery block overlay, which locks out the screen while it is querying data or redrawing the screen.

tia,

Al

[Alister Scott]

I'm getting the same error quite frequently when using watir-webdriver.
It is happening near where I used execute_script to execute some javascript on a div, like "onclick"

[Jari Bakken]

This usually happens when the element has been removed from the DOM
after the element was located, and is usually an indication that
you're not waiting for the page to be in the expected state before
using the element. Relocating the element would also solve this
problem, e.g.:

https://gist.github.com/1118078

> --
> Before posting, please read http://watir.com/support. In short: search
> before you ask, be nice.
>
> watir-...@googlegroups.com
> http://groups.google.com/group/watir-general
> watir-genera...@googlegroups.com
>

[Jarmo Pertman]

In Watir the locating of the element will be done automatically - why
not use the same approach in Watir-WebDriver? Is there any good reason
to do that?

It just sucks that i can't write code similar to this in watir-
webdriver:
container = browser.div
# do something, which obsoletes the element, but makes it exist again
container.do_something # this should work

As i understand from your gist then #do_something won't work unless i
specifically tell again that container = browser.div. Why?

Jarmo

On Aug 1, 4:01 pm, Jari Bakken <jari.bak...@gmail.com> wrote:
> This usually happens when the element has been removed from the DOM
> after the element was located, and is usually an indication that
> you're not waiting for the page to be in the expected state before
> using the element. Relocating the element would also solve this
> problem, e.g.:
>
> https://gist.github.com/1118078
>
>  On Sun, Jul 31, 2011 at 12:58 PM, Alister Scott
>
>
>
>
>
>
>
> <alister.sc...@gmail.com> wrote:
> > I'm getting the same error quite frequently when using watir-webdriver.
> > It is happening near where I used execute_script to execute some javascript
> > on a div, like "onclick"
>
> > --

> > Before posting, please readhttp://watir.com/support. In short: search

[Jari Bakken]

On Mon, Aug 1, 2011 at 5:41 PM, Jarmo Pertman <jar...@gmail.com> wrote:
> In Watir the locating of the element will be done automatically - why
> not use the same approach in Watir-WebDriver? Is there any good reason
> to do that?
>
> It just sucks that i can't write code similar to this in watir-
> webdriver:
> container = browser.div
> # do something, which obsoletes the element, but makes it exist again
> container.do_something # this should work
>
> As i understand from your gist then #do_something won't work unless i
> specifically tell again that container = browser.div. Why?
>

That code will work just fine, since the div isn't located until you
use "container". However, you'll need to re-locate if the element was
used once (and thus located and the reference saved), then removed
from the page and then used again, like in my example.

That behaviour is up for debate, but personally I've always considered
the current behaviour more helpful than not: it tells me very
specifically where my expectations are wrong and where there are
potential race conditions. Automatically re-locating gives me less
information about the interaction between the test and the app than
the ObsoleteElementErrors do, which helps me write more robust tests.
The application's behaviour isn't hidden from the test author, and
that's always a good thing IMO.

Another benefit is the overhead saved by not having to go through the
"locate" algorithm every time the element is used, which I believe is
what happens in Watir. If you're reusing Element instances heavily,
Watir-WebDriver benefits from caching the element reference.

That being said I do see that this is a break with Watir 1.X and
somewhat inconsistent with Watir's element objects, where you never
really know whether the element is "live" or not (by re-locating on
every use). The current behaviour is sort of a compromise between
Watir's Element objects that just stores *how* to find the element,
and what you'll find in WebDriver, where every Element instance
*always* is a pointer to a DOM node.

Any other opinions on this?

[Alister Scott]

I have found testing an app that has a crazy amount of JavaScript that changes the DOM, that these exceptions are raised quite frequently.

I personally prefer the Watir 1.X behaviour, as it personally means tests are more reliable for me.

But, I understand the performance hit. Are we talking much slower execution times?

I have written about this on my blog, with some ideas I have on how to write scripts to avoid it: http://watirmelon.com/2011/08/02/watir-webdriver-obselete-element-error/

Cheers,
Alister

[Jari Bakken]

Den 2. aug. 2011 kl. 14:19 skrev Alister Scott <aliste...@gmail.com>:

But, I understand the performance hit. Are we talking much slower execution times?

I don't think locating elements is the major bottleneck in browser tests in general, but it certainly can be in some cases. This is especially true with WebDriver, where every call to the API is also an RPC. We won't know until we try, I guess - I can create a branch where we can experiment. 

The problem is finding good benchmarks. The easiest choice would be to just run watirspec, but it almost never re-uses Element objects, so the performance hit will likely be lower than in a real world test suite. It's also rare for the specs to do "nested finds" (e.g. browser.div.text_field), which would also be affected negatively. 

Jari

[Jari Bakken]

On Tue, Aug 2, 2011 at 9:44 PM, Jari Bakken <jari....@gmail.com> wrote:
>
>
> But, I understand the performance hit. Are we talking much slower execution
> times?

I've changed the behaviour on the no-element-cache branch:

https://github.com/jarib/watir-webdriver/tree/no-element-cache

Please try it out and let me know what you find. Taking into account
the comments about using watirspec as a benchmark in my last email,
the change appears to add about 10 seconds to the test run (from 145
seconds to 155 seconds) on my machine.

Jari

[Alister Scott]

Awesome! Thanks.

I switched to this and ran a test suite and it took 6 seconds longer than usual (usually 59 seconds), but I am more than willing to accept this to have a much more reliable test suite.

I vote for having this changed, I am sure Zeljko would vote for it too considering how much trouble he's having.

If you're not in favor of switching to this, could we at least make it user configurable to have this behaviour?

Thanks,
Alister

[Alister Scott]

Tested the new version with configurable option and all good, thanks Jari.
Can we please have a new gem version now?

[Alister Scott]

This has been released. Thanks to Jari.
See an article about how to use it here: http://watirmelon.com/2011/08/14/telling-watir-webdriver-to-always-locate-elements-upon-use/

[Jarmo Pertman]

I'd even vote this to be enabled by default :)

Jarmo

On Aug 14, 7:45 am, Alister Scott <alister.sc...@gmail.com> wrote:
> This has been released. Thanks to Jari.

> See an article about how to use it here:http://watirmelon.com/2011/08/14/telling-watir-webdriver-to-always-lo...

[Jari Bakken]

It is enabled by default.

Den 14. aug. 2011 kl. 10:44 skrev Jarmo Pertman <jar...@gmail.com>:i

> --
> Before posting, please read http://watir.com/support. In short: search before you ask, be nice.
>
> watir-...@googlegroups.com
> http://groups.google.com/group/watir-general
> watir-genera...@googlegroups.com

[Jarmo Pertman]

Nice. Alister's blog post seemed to tell differently.

Jarmo

On Aug 14, 3:15 pm, Jari Bakken <jari.bak...@gmail.com> wrote:
> It is enabled by default.
>

> Den 14. aug. 2011 kl. 10:44 skrev Jarmo Pertman <jarm...@gmail.com>:i

>
>
>
>
>
>
>
> > I'd even vote this to be enabled by default :)
>
> > Jarmo
>
> > On Aug 14, 7:45 am, Alister Scott <alister.sc...@gmail.com> wrote:
> >> This has been released. Thanks to Jari.
> >> See an article about how to use it here:http://watirmelon.com/2011/08/14/telling-watir-webdriver-to-always-lo...
>
> > --

> > Before posting, please readhttp://watir.com/support. In short: search before you ask, be nice.
>
> > watir-...@googlegroups.com
> >http://groups.google.com/group/watir-general
> > watir-genera...@googlegroups.com

[Mattias Karlsson]

Ok, so we are trying to do an exist? call on an  element that is shown after clicking a button, which executes some javascript, but it seems like it still is failing for us with this new update to watir-webdriver (it's calling the DOM error in our script). As it is intermittent, perhaps it's more of a timing issue? (as in the script is running before the jquery). Wait_until doesn't really work, but a sleep will do, but as this is bad practice, I would rather see this fixed some other way. Any suggestion here guys?


When /^I am selecting (.+) period$/ do |cool_off|
   on AccountCoolOff do |page|
     page.cool_off_period_select_value= cool_off
     page.confrim_cool_off
     sleep 5
   end       
end

Then /^I should see Account Cool Off (\d+) date$/ do |cool_off_date|
      on AccountCoolOff do |page|
      wait_until{page.cool_off_submit_link.exists?}
      @current_date = ((Date.today + cool_off_date.to_i).day).to_s
      wait_until{@browser.text.include? @current_date}
      page.cool_off_submit
      end 
end

[Alister Scott]

Did you switch back the behaviour to see if it works?
Can you provide some sample HTML/JavaScript code?

Watir::always_locate = false
b = Watir::Browser.new

[Jari Bakken]

Some people are reporting quite significant performance issues after this change:

  https://github.com/jarib/watir-webdriver/issues/92

Jari