Some Adapter.Click Methods Open IE ContextMenu

Experiences, small talk, and other automation gossip.
AlexRTT
Posts: 1
Joined: Fri Oct 24, 2014 4:02 pm

Some Adapter.Click Methods Open IE ContextMenu

Post by AlexRTT » Fri Oct 24, 2014 4:21 pm

Hi,

since recently I get sometimes strange behavior in our tests.
When performing a click on an element, the IE context menu appears instead of the expected action.
It does not happen because of ALT + SPACE shortcut nor does the mouse move to the left upper corner of IE's window before the click, it just behaves as if one of these would happen and does not perform the expected click.

The first of those lines is executed as expected but in the last one, the application does not react to the click but IE opens the context menu at the upper left corner. (In between there is just some logging and a get attribute value of _button)

Code: Select all

...
_button.MoveTo();
Delay.Milliseconds(500);
...
_button.Click();
...
Did anyone ran into anything like that or has any suggestions about what to do?
It usually works but in some cases and on some elements only this issue occurs.

Thanks in advance,
Alex

PS:
OS: Win 7 x64
Browser: IE 10
Testing a flash application
Ranorex version 5.1.1

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by krstcs » Mon Oct 27, 2014 1:28 pm

Alex,

Do you have your mouse buttons reversed in Windows?

I believe (could be wrong) Button.Click(), by default, clicks the LEFT mouse button. If you have your mouse buttons reversed in Windows, this would cause any application in Windows to register the LEFT click as if it were the RIGHT click and present a context menu.
Shortcuts usually aren't...

dman
Posts: 64
Joined: Mon Aug 29, 2011 9:33 am
Location: München

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by dman » Tue Oct 28, 2014 11:00 am

mouse buttons are not reversed

(working with Alex on the same project)

krstcs
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by krstcs » Tue Oct 28, 2014 2:52 pm

Hmmm...

Could you post the solution here? If not, could you post a sample solution that has the same issue? Might help the support team see what you're dealing with a bit better.

Also (just throwing some stuff out here...), are you using any modifier (Shift, Alt or Ctrl) keys in the test before this click? Could one of those be sticking maybe, or have a DOWN and no UP? Also, could accessibility features be turned on?
Shortcuts usually aren't...

JSH_QA
Posts: 56
Joined: Thu Apr 05, 2012 9:03 am

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by JSH_QA » Mon Nov 03, 2014 1:46 pm

Hi Alex,

We've seen the same thing occur during development of tests, although not in a completed test implementation. I believe the only occasions that this has happened have been when rather than doing

Act, Confirm, Act, Confirm,

a test has instead done

Act, Act, Confirm.

If something about the first Act in that latter sequence fails, the next Act will be operating on an application under test that is in an unexpected state. A menu appearing at the top left of the screen is a typical symptom of this happening, where a mouse-click happens somewhere, or on something, other than where intended.

To put this into context, suppose you are automating clicking on the File/Save As menu option. This would involve clicking on File to drop down the File menu, then clicking on the Save As option. If that is coded as:

click on File, click on Save As, validate that the Save As dialog appears,

rather than:

click on File, check the File menu appeared, click on Save As, validate that the Save As dialog appears,

if the File menu did not appear, the next click (depending on how it is coded) could result in unexpected behaviour.

Hope this helps,

John H.

JSH_QA
Posts: 56
Joined: Thu Apr 05, 2012 9:03 am

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by JSH_QA » Thu Nov 20, 2014 8:29 pm

We saw another example of this today, with a related, but slightly different scenario.

The scenario seen today is as follows:
The application under test (AUT) contains an edit box
As the user types into the edit box, the application tries to implement auto-complete. When it finds one or more matches, it drops down a list box containing the matches, then a fraction of a second later, it updates the edit box to contain the text typed so far followed by the remaining characters from the first matching entry, but with those characters selected and with the caret still in its original place at the end of the text actually typed into the edit box (so before the selected text).
In this, there appear to be two pieces of asynchronous code, the first dropping down the list box, the second appending selected text to the edit box and resetting the caret position.

What the automation was trying to do, was to type text into the edit box, then when the dropdown list appears, to move the mouse pointer (over a non-zero time period, I think 300ms) to the first entry in the dropdown list, and then left-click on it.

What is seen to happen is that the text is typed and the mouse pointer moves to the first entry, but then the mouse pointer moves to the top left of the window.

What seems to be happening is that the ListItem's Adapter is obtained for the first entry in the dropdown list, but somewhere in the asynchronous behaviour of the application under test, by the time the Click operation is called, the ListItem is no longer enabled/valid (the asynchronous resetting of the caret position would appear to trigger this change). At this point, presumably when the Click method is called, the mouse moves to the top left of the window.

We worked around this quite easily, but with asynchronous behaviour in applications under test, it is something we have to watch out for. Basically, between the point where you get an Adapter/Element for a control in your AUT and the point where you subsequently Click on it, asynchronous behaviour in the AUT may have invalidated the Adapter/Element.

Regards,

John H.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by Support Team » Fri Nov 21, 2014 2:27 pm

Hi John H.,

Thanks for sharing your experiences.
You wrote that you "worked around this quite easily", could you also share your solution to this situation?
This would also help others in a similar situation.

Thanks,
Markus

JSH_QA
Posts: 56
Joined: Thu Apr 05, 2012 9:03 am

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by JSH_QA » Fri Nov 21, 2014 3:06 pm

Hi Markus,

Unfortunately, the workaround in this particular scenario can only be used in a small number of cases, but the general principle is reusable.

The general principle is:

Basically, what the automated test needs to do is to avoid interacting with a control that may change state between the point where the Adapter for the control is obtained and the interaction is performed/completed (whether because of asynchronous behaviour that would happen in the AUT anyway, or because of behaviour resulting from the interaction - such as mouse movements resulting in mouse events being processed). Quite simply, avoid race conditions.

In the scenario described, the workaround was:
(1) Type the text (let’s call it T1, an example being "John") into the edit box.
(2) Wait for the first matching element to be visible in the dropdown list (first known asynchronous behaviour in the AUT).
(3) Get the text T2 of the first matching element (which could be "John" or "John H"), which will be at least as long as T1. Getting the text of the element does not move the focus, mouse pointer etc., so does not trigger the AUT to do anything.
(4) Wait for the text T2 to appear in the edit box (second known asynchronous behaviour in the AUT).
(5) At this point, all of the asynchronous operations performed by the AUT have finished, so we can now do the next operation, which in this scenario is to move the focus to another control and enter some text there.

So the workaround is very simple in this scenario – it was simply to achieve the desired functionality (to type some text into the edit box and populate the edit box with the first match from the dropdown) in a different way, so that we wait for asynchronous operations to complete, rather than have a race condition where we are trying to do a sequence of operations that asynchronous behaviour in the AUT might interfere with (in this case, the AUT was still adding items to the dropdown, moving the selection when we hovered over an item, and moving the focus and selection when it populated the edit box). The different way used avoids doing anything (moving focus, hovering over a different control etc.) that might result in additional asynchronous behaviours from the AUT, and waits for the asynchronous operations that we know about to complete before we do anything more.

Regards,

John H.

User avatar
Support Team
Site Admin
Site Admin
Posts: 12145
Joined: Fri Jul 07, 2006 4:30 pm
Location: Houston, Texas, USA
Contact:

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by Support Team » Mon Nov 24, 2014 4:05 pm

Thanks John for your explanation :)!

I just wanted to add that it is inn general also possible to select a specific list item by not using the mouse but by using the SetValue or Invoke action.

Regards,
Markus

JSH_QA
Posts: 56
Joined: Thu Apr 05, 2012 9:03 am

Re: Some Adapter.Click Methods Open IE ContextMenu

Post by JSH_QA » Mon Nov 24, 2014 4:49 pm

Thanks Markus,

Yes, wherever possible our code allows us to run our test suite using either mouse or keyboard or touch or invoke action, based upon configuration. There are places where there is no invoke action equivalent (e.g. right-clicking on a System Tray button), but for most things we can configure how we want to run.

Thanks,

John H.