Clicks on the wrong hyperlink

[Jean-Pascal van der Endt]

Hi,

We have the following problem. Some webpages contain particular HtmlControl elements (in my example below, an HtmlAnchor) for which we can find a reference without any problems (using browser.Find.ByExpression<>), but when we call .Click() on that element, the click event seems to end up on a completely different element in the DOM. We notice this because the browser ends up loading a URL that corresponds to a different HtmlAnchor in the document, which causes our scenario to fail. Obviously this is a big problem for us.

The strange thing is that this issue seems to be timing related. Please consider the following code fragment:

           

browser.NavigateTo("http://example.com");

// Do some simple interaction with the page,
// e.g. using textboxes and buttons to log into the website
// [code omitted]


// Problem occurs here:
// WITHOUT this Sleep statement, the following .Click() is executed correctly.
// WITH this Sleep statement, the .Click() ends up on the wrong DOM element
Thread.Sleep(4000);

var link = browser.Find.ByExpression<HtmlAnchor>("href=some-href-value-in-the-page");
link.Click();

With the delay caused by the Thread.Sleep statement, or just by setting a breakpoint and breaking in the debugger, or some other delay or timing dependency, the link.Click causes the browser to load a completely different URL.

Just to be clear: the link variable does have a reference to the correct element; it’s the .Click (or indeed any other interaction with that element) that ends up being executed on a different DOM element.

Other details:
-    Same problem occurs when I use a different Find method to find the element
-    I suspect that this happens for other HtmlControls as well
-    I’m using Telerik Testing Framework (2011.1.712) – Framework Only version
-    I’m using combinations of Internet Explorer 8/Windows 7/Windows 2003/Windows 2008

I have a very small example project that reproduces the problem on the website of one of our customers. Since the project contains some sensitive login info, I’m not comfortable posting the project here. Can I send the project via Dropbox or email?

Thanks for your continued support, we appreciate it.

Regards,

JP

[Stoich]

Hello Jean-Pascal,
    I understand the problem. Timing issues and identifying the wrong elements are a part of UI Automation and can occur for a variety of reason.

Often timing issues can be caused by not properly waiting out AJAX queries to complete:
http://www.telerik.com/automated-testing-tools/support/documentation/user-guide/knowledge-base/test-automation/ajax-postback.aspx
But that's just one of many possible reasons.

Getting the wrong element is usually due to unreliable Find Logic.

However, I find something very puzzling in your case:
The Find Logic you're using for the Anchor is based on the Anchor's HREF. This means that regardless of what Anchor element you're locating, it's still an anchor element that has that exact HREF. If you're clicking on that Anchor that means that the browser is attempting to navigate to that specific URL. Because of this I find it quite strange that depending on the timing you're navigate to different URLs.

Is it possible that some sort of a redirect functionality kicks in at some point?

All the best,
Stoich
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Jean-Pascal van der Endt]

Hello Stoich,

Thanks for responding so quickly, and for your suggestions regarding waiting out AJAX actions.

Good point regarding the redirect, too. I checked it - there is a redirect, but the *initial* request (that gets the 302 response) is already wrong.

And yes, it's puzzling. The Anchor I'm getting out of the Find logic is the correct one. When I inspect it in the debugger (or using Trace statements), I can see that it's the element I'm looking for. It shows all the attributes I was expecting, including the right HREF attribute.

The URL that gets loaded in the browser, however, is the one from the HREF of the preceding Anchor. I've seen similar cases where we seem to be clicking on the preceding Anchor. Or, in case of filling in a textbox, the new text value ends up in the preceding textbox.

It feels like there is some sort of indexing problem? I mean, I guess that the HtmlControl from the Find methods are eventually mapped to an indexed element in the Dom tree? Is it possible that there is some sort of mismatch there?

I've tried using more RefreshDomTree statements, which does help sometimes, but not always. And even then, I'm puzzled by the fact that if I have *no* delay/wait clause between the previous click and the next click, that it does work. It would make more sense if it was the other way round.

Thanks for looking into it, and for any suggestions. I'm happy to provide a test project that reproduces the problem.

[Stoich]

Hello Jean-Pascal,

So-called "indexing" issue do sometimes occur when performing UI Automation. However, I find it unlike that this is the issue you're experiencing. This is because the Find Logic you're using is not based on TagIndex or Xpath and this makes it far less likely that we're somehow getting the wrong element. I'm very curious as to what the actual reason for the problem is.

@I'm happy to provide a test project that reproduces the problem.
This is definitely the best option in this case. Make sure that the app is publicly accessible (i.e. we'll be able to run your test and see the issue first hand). I can provide a private e-mail if you feel this info is too sensitive for a public forum.

Regards,
Stoich
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Jean-Pascal van der Endt]

Hello Stoich,

Sorry for the delay in getting back to you. Thank you for your insight.

I did make some progress in the meantime; it seems that the DOM (or its representation in the datastructure that your code is using) is changed in between the Find method and the action we're doing on that element (e.g. a .Click).

It does work better when I do an extra RefreshDomTree(). Obviously this gets a fresh look on the DOM. However, we're still seeing issues in our production environment, although that may be hard to reproduce using my test code.

Still, I'd like to submit my code so you can see the discrepancies. The website in question is publicly available, so you should have no problem reproducing the issue. Can you let me know where to send the project? Thanks in advance.

Regards,

Jean-Pascal

[Stoich]

Hello Jean-Pascal Van Der Endt,
   I've went ahead and sent you a private e-mail. You may attache the necessary data in your response. Please also respond here once you've sent the data - this will help us keep track of the issue.

Greetings,
Stoich
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Jean-Pascal van der Endt]

Hello Stoich,

Thanks for your e-mail; I have sent my test project to your e-mail address, along with an analysis of the problem.

Regards,

Jean-Pascal

[Stoich]

Hello Jean-Pascal,
     at first when I started working on this issue I was able to reproduce the problem. However, eventually I stopped seeing it. Because of this I was not able to determine the specific causes for this problems, it's some kind of timing issue. It was quite peculiar.

Instead of locating the anchor by its href I would like to suggest something different:
The href element actually contains an img element (screenshot 1). Instead of trying to click the href you can invoke the click on this image like so:

HtmlImage NavShopImage = Pages.SnakeRepellentsSnake.NavMoleImage;
NavShopImage.Wait.ForExists(10000);
Assert.IsTrue(NavShopImage.IsVisible());
NavShopImage.Click();

With this implementation we app always navigated to the correct page (Mole repellants) and I never experienced any issue.

Let me know whether this is a workable workaround for you.

Kind regards,
Stoich
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.