Pop-up hiding behind parent window in Solaris

Question

question

ramarb asked Apr 16, '09 ramarb posted Apr 16, '09

Pop-up hiding behind parent window in Solaris

I execute a swing test script which was developed in Windows in Solaris box.

Some dialog boxes are going behind the parent window. As a result of this, iTest can't find that pop-up.

The following error shown in report; test case fails.

Fail swing EMSClie 83 83 main Action failed: The specified target: //button[@name='OptionPane.button' and @text='Yes'] could not be found

I have numerous test cases in Swing, and I have started porting them into Solaris. Logically, the same scripts should hold good for Solaris, I believe. Please advise.

iTest GUI Testing(Web-Java Swing-etc)

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-04-17T09:06:22Z

ramarb answered Apr 17, '09 ramarb posted Apr 17, '09

The pop-up window object exists in the application though it went behind. iTest is just not clicking the button.

I have chosen the relative coordinates option, from the default first option, in properties to get out of this issue (see attachment)

But, my biggest problem is I have lots of steps like this in different scripts. How can I address them? It looks like an iTest bug in solaris. Anyways?

Solaris version::

bash-3.00# uname -a
SunOS Taurus 5.10 Generic_120011-14 sun4u sparc SUNW,A70

MouseClick.JPG (22.7 KiB)

12

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

PaulD commented · Apr 17, 2009 at 03:29 PM

If the window goes behind and we use the robot to click the mouse, then I can see why it wouldn't work. The mouse click will be registered on the window that is obscuring it.

0 ·

PreetS PaulD commented · Apr 17, 2009 at 05:31 PM

ramarb,

I am not sure how changing the mouse properties is solving your problem. What happens when you manually click on the button that brings up the popup on the solaris machine? Does it go to the background by default?

0 ·

ramarb PreetS commented · Apr 17, 2009 at 05:52 PM

I will make one thing clear is that pop-up is no longer goes behind the window now. It was quite inconsistent and could not see that now. (changed the title of the thread)

However, default clicking does nothing on the pop-up window; meaning the pop-up simply pretend as it is being accepted the click action but actually its not.

When I chose the second option, it works just fine. I did the same for 4-5 buttons which responded well.

Meanwhile, I will raise a support case for this since it poses a potential challenge to our testing.

0 ·

ramarb PreetS commented · Apr 30, 2009 at 08:58 AM

Oops... I am seeing this window goes behind the the main window. iTest is not able set values in the window which hides in the show.

I think the main window is stopping click action, setValue action since it just eclipses the other window. Af a result of this, test report claims 'Action failed: Target not found' error. Please see attached test report and the application in problem state.

In Manual testing, it appears always on front. I don't know who is playing spoilsport; either our application or iTest.

Any idea of how to troubleshoot it further?

Thanks!

0 ·

swing_windowIssue.zip (248.6 KiB)

PreetS ramarb commented · Apr 30, 2009 at 03:26 PM

I am not sure who's at fault here, but iTest does not do anything specific to move windows back and forward.

Is there an action that causes the popup window to come up, like you click on a button and that brings up the popup, or does that popup appear when you launch the application?

0 ·

ramarb PreetS commented · Apr 30, 2009 at 05:15 PM

It comes up when clicking 'Create' button of 'Qos Parameters' window (check the snapshot). This Qos Parameters window was invoked using menu item Global Config -> Qos Parameters

I have been seeing this issue in many windows, thereby test case is failing. Sometimes, it works correctly.

Message Edited by ramarb on 04-30-2009 10:47 PM

0 ·

PreetS ramarb commented · Apr 30, 2009 at 05:23 PM

I am wondering if this may be due to VNC you are running or some other DISPLAY configuration, because I know you are running it remotely.

Just a hunch.

0 ·

ramarb PreetS commented · May 04, 2009 at 06:18 AM

Preet,

To clarify your doubt, I have executed the test case directly in Solaris. In this case also, I see the window hiding behind the other and does not accept keystrokes, settext and click actions.

Basically, iTest has to do all these actions irrespective of the fact that wherever the window is. This is a distinct feature in iTest!

Hence, it looks like an issue with iTest.

Please let me know your comments.

Thanks.

0 ·

KumarS ramarb commented · May 04, 2009 at 07:00 AM

Can you try the following:

Start your application manually. Get to the state where you get the extra window. Now click on the main window. Does the other window get behind the main window? If it does, then it is not a modal window. Now there are two possibilities:

1. There is a step in the testcase which causes the main window to get focus.

2. There is a bug in iTest where it incorrectly activates the main window while trying to work with the other window.

0 ·

ramarb KumarS commented · May 04, 2009 at 07:13 AM

Thanks for the information, Kumar.

I told this in earlier post, the other window not goes behind the main window in manual testing. The other window is a modal one which does not allow to activate main window (in manual testing)

I am attaching my test case here. There are a successive click items which launch these windows; no other steps between them.

Message Edited by ramarb on 05-04-2009 12:46 PM

0 ·

window_issue.JPG (99.9 KiB)

PreetS ramarb commented · May 11, 2009 at 06:16 PM

Hi Ramar,

The setText action that is right after the "the step that will launch the child window; is that setText on the child window or another control on the parent window?

This will help me debug the issue.

Thanks.

0 ·

ramarb PreetS commented · May 12, 2009 at 04:55 AM

setText step is for child window only. There is no such target presents in main window! I have checked that.

0 ·

Answer 2 · 2009-04-16T17:13:30Z

PreetS answered Apr 16, '09 PreetS posted Apr 16, '09

iTest does not need the window to be on top to find a target. It seems like it is just not finding the target. Either the popup is not there or the target does not match.

A good start to debug this is to put a "snapshot" step before the failing step. This will give you the XML of the DOM that iTest creates. We can look through the XML and see if the popup window is there or not.

Since snapshot is taken instantly, you may want to put a sleep before the step so that your application has opened all the windows by the time snapshot is executed. Again, it depends on your application and test case, so you may not need to.

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

question