I had this problem too.
Now I'm calling Thread.sleep(500) to solve this bug.

Any idea when this is going to be fixed?

I also have this problem. In addition I also have problems using waitForPageToLoad in firefox. It might be related to the way we do the requests (click builds a form in a hidden frame which is submitted and has a target of the originating frame.

I solved the problems by doing this

session().getEval("selenium.browserbot.getCurrentWindow().document.selenium_dummy = 'reloading'");
session().click(click);
session().waitForCondition("try {var doc = selenium.browserbot.getCurrentWindow().document;doc.readyState == 'complete' && doc.selenium_dummy == undefined}catch(err){false}", Element.TIMEOUT);

Reduced priority as the issue has been reported about a nightly snapshot, which must not be stable. Furthermore, there are workarounds like waiting for a checkpoint element.
Is the error still reproducible with an actual released version, like 0.9.2 AND 1.0 beta 1?

This crops up consistently for me when running Selenium 1.0-beta1 on Linux. I'm using Firefox v2.0.0.17, Selenium server 1.0-beta1, PHP client libraries (with PHP v5.2.5), and JDK v1.6.0_10. Similar to previous posters, I can work around the issue with a sleep. This doesn't happen for me 100% of the time, but it happens frequently enough that my test cases don't work properly. I haven't observed the same issue when running under Windows, using the same version of Selenium, Java and Firefox.

I had the same exact problem with Selenium 1.0 beta, under Vista.
It seems related to a POST into a frame, and SeleniumRC crashes with this error message (also, I didn't find it in the source !).

Here is an excerpt:

selectFrame navbox
clickAndWait btnOK
selectFrame relative=top
verifyTextPresent message

I get:
Couldn't access document.body.  Is this HTML page fully loaded?
on the last line.
I'll add a function to wait for page completion, since AndWait seems unable to do it correctly.

I dug onto this problem, and here are some remarks:

1) We can fix it by using the following function:
Selenium.prototype.isBodyReady = function()

and use
waitForBodyReady

2) The problem appears when several pages are loaded simultaneously.
It seems that Selenium Core only catches the first one, and doesn't care about the others.
I think it may be due to some bugs in Selenium Core, since it uses for example getCurrentWindow() to locate a frame in browserbot.js. The correct call is getCurrentWindow(true), in order to avoid clearing the pageLoad flag.
In general, the newPageLoaded flag is incorrectly handled.

3) IMO, I think it's a bug in ReadyState.xpi, which correctly catches when a page is reloaded, but not when it's ready (I mean you can open the document.body).

With the following code lines when using the latest snapshot I can't reproduce this issue:

selenium = new DefaultSelenium("127.0.0.1", 5555, "*firefox", "http://www.google.at");
selenium.start();
selenium.open("/");
selenium.type("q", "seleniumhq");
selenium.click("btnG");
selenium.waitForPageToLoad("60000");
selenium.isTextPresent("selenium-ide");

As some of you mentioned frames what about using waitForFrameToLoad()?

I tried waitForPageToLoad, and waitForFrameToLoad, but they both fail.

As I said, I have to run the test around 3 times to get an error, and the test has around 10 of such tricks.
This means that it fails around 1 out of 30 times.
My configuration is Vista SP1+Firefox 3.
I'll try to create a small test that fails...

The waitFor/Condition logic in the Java client driver now caters for this (amongst other unexpected SeleniumExceptions). You won't need to code a manual sleep() operation as waitFor will do this functionality silently, and try to recover before timeout.

If the wait/For stuff gets ported to PHP, Python etc, then other languages will see this too.

I'm seen this error with 1.0 Beta 2. It is very intermittent (like once of every 8 runs). Of course to make things more difficult this is never happening in development but only on the continuous integration server.

I forgot to mention in my previous comment that we never ran into this problem when running selenium server 0.9.2 (and we had been running it for about a year).
We have seen this problem on a regular basis with 1.0 beta 2, which we have been running for about 3 weeks now on our continuous integration server.

To everyone that is watching this issue: what mode are you running this in? Does it go away if you switch the mode to a different mode?

Running with chrome mode. Don't have an answer for your question. Which mode should be tried?

Theirry - chrome mode should be fine, but can you try some of the other ones listed here:

http://clearspace.openqa.org/community/selenium/blog/2009/01/13/selenium-rc-beta-2-goodies-and-gotchas

Particularly *firefoxproxy with and without -proxyInjectionMode turned on.

Getting the same problem with Firefox 3.0.7 and Selenium RC 1.0 beta 2. In my case it fails all the time with any of those modes: *chrome, *firefox, *firefoxproxy. Any suggestion?

@Pavel: Can you share your test?

Any progress or movement on this?

I'm also experiencing this issue with selenium rc 1.0.2 with ff 3.0.13

I'm seeing a different form of this error with rc 1.0.1 and FF 3.0.x. Instead I get lots of "X is undefined" errors during our tests using the waitForCondition() method.

Cause it is an intermittent failure, it is hard to tell but I think it is when I use the *firefox mode (seems to be ok with *firefoxproxy). I also see this a lot in our automated build system and not as much running the tests locally during development. Like Thierry, we never saw this problem previously when we were on 0.9.2.

I also forgot to mention we are using singleWindow mode (multi window mode seems to slow down our automated tests).

We see this as well, running in both *firefox and *iexploreproxy modes. Our work-around has been to wrap IsTextPresent() and to call WaitForCondition("selenium.isElementPresent('document.body');", ...) first. It's a kludge, but it seriously reduces the random-failure count.

Here is the workaround that we use in our user-extensions.js.
It overloads the makePageLoadCondition in order to wait for the <body> tag to be completely loaded.
Sorry for the ugly try/catch...

Selenium.prototype.makePageLoadCondition = function(timeout) {
if (timeout == null) { timeout = this.defaultTimeout; }
// if the timeout is zero, we won't wait for the page to load before returning
if (timeout == 0) { return; }
return Selenium.decorateFunctionWithTimeout(fnBind(function()
{
try

catch(ex)

return this.browserbot.isNewPageLoaded();
}, this), timeout);
};

Here's what we use:

public static boolean isTextPresentSafe(String text) {
boolean present = false;
try { present = itsBrowser.isTextPresent(text); }
catch (SeleniumException e) {
if(!isSeleniumBugSRC302(e)){ throw e; }
}
return present;
}

/**

• Hack to work around: http://jira.openqa.org/browse/SRC-302
  */
  private static boolean isSeleniumBugSRC302(Exception e) { String message = e.getMessage(); return message.contains("Couldn't access document.body"); }