Selenium 2 cant find element ID unless I go directly to the .aspx file

Question

So I'm trying to make the conversion to Selenium 2, but I seem to have an issue were if I go to http://website.com, Selenium cant find the elements of my aspx form. I need to have Selenium go directly to http://website.com/form.aspx. This isnt horrible because I can make sure the forms work, but ideally I would like it to complete everything from the users point of view. Has anyone else had this issue?

Answer 1

It seems that there's a redirection from the default main page to the form.aspx on your site. I think that WebDriver catches the completion of loading of the main page which then redirects to the form, but WebDriver is not catching this.

I think that you can either introduce a delay before starting finding elements, or you can use PageFactory with AjaxElementLocatorFactory which will allow your driver to wait until controls will really appear, but I am not sure if it is available for C#

Answer 2

I had this problem too, it is due to the redirect, and that the waitFor* command doesn't quite work well with redirects. It will never wait for 2 pages (which is what we need here), but if you put 2 waits back-to-back (which is in theory the right thing to do), often the 2nd one will hang. It appears to be some kind of race condition since it's unpredictable, 90% of the time it seems to hang though

So what I did was just spin in a loop until I saw some signal on the page after the redirect that I expected to see. You can have the signal be that control you're looking for for the actual test too. My solution, a short block of perl, which I'm sure you can translate to C#:

$sel->open('/some/page/that/will/redirect/us');
$sel->wait_for_page_to_load("30000"); #wait for the redirect to hit
do {       
   $sel->pause(50); #now spin while we're in no-mans land

   #until you spot what you need:
   last if $sel->is_text_present('This is the Real Home Page'); 
} while( 1 );

#carry on.... redirect is completed and page is loaded

A happy bonus of this is that the command history log counts up the milliseconds on "Same command (99ms): xyz" as it spins, letting you know everything is alive and healthy while the redirect takes its course.