I have been running into intermittent errors with some java selenium-rc tests which I think are related to a page which has an ajax poll and automatically refreshes when some condition is reached on the server. In this scenario, I have no way of asking selenium to wait for the page to load, and so I run into a bunch of random "Couldn't access document.body" errors.

So, is there some way I can cause selenium to gracefully handle this situation? If not, is there some way I could detect whether the user is selenium from the page's javascript, and disable the automatic refresh?

If it helps at all, the javascript code in the page looks something like...

3 Answers
3

The simple solution would be to have selenium execute a script to override/disable the javascript that self refreshes. I can't remember if selenium rc is selenium 1 or selenium 2, but it rexecuting javascript can be executed from both drivers. That aside, @Hannibal has a pretty good solution, and I would most likely do it that way myself

If Hannibal's answer doesn't work, what has worked for me with pages that take a very long time to load, is adding calling a method either directly after the action which causes page to be refreshed, or, at the beginning of the next action, which checks to see if a particular element which will always be present on the page, is actually present.

Was writing an answer as you posted this. I think that I'm going to see about implementing your solution in my own automation as this seems much more efficient.
–
Lyndon VroomanMay 6 '11 at 11:12

Would that just wait for the ajax request and the onComplete handler to finish, or would it wait until the new page (which is loaded by window.location.replace) is full loaded?
–
Matt SheppardMay 6 '11 at 11:12

@Lyndon: Thanks man. :) @Matt: This actually waits for EVERY jQuery request to finish. It waits until everything jQuery does on your page is done, even for a microsecond. If jQuery get's in the state: active=0 your program will continue. This of course is only valid for jQuery, but you can edit this to represent whatever tool you are using. Btw if you are not using jQuery, shame on you you should. :D
–
HannibalMay 6 '11 at 11:26

Thanks - I'll try it out. I'm still not sure it will work though, because I would have assumed that when the window.location.replace started loading a new page, the old jquery context would need to be destroyed. Assuming that happens, jquery wouldn't actually become active again unless the new page which is being loaded used it for something, and even then there would be points during the page loading where it was inactive. That said, I'm not sure so I'll test it out and see if you're right that jQuery.active survives through a page load.
–
Matt SheppardMay 8 '11 at 11:18

Yeah i hope it helps. It's just an idea after all. I really hope that will help you get from there at least.
–
HannibalMay 9 '11 at 7:08