IE7/WinXP cannot close 'Windows Internet Explorer' dialog

[Optimus]

I am using MacroScheduler 8.1 (Eval) to run a script generated by WebRecorder. The script enters username and password on the first visited page. Upon submission via FormFill (or clicking on the submit button via clicktag), a javascript method is called that validates the user input and opens a new browser window.

During this process a dialog appears titled 'Windows Internet Explorer', stating that the current page is asking to close the window, with 'yes' and 'no' buttons, 'yes' in focus. This dialog does not appear when generating the script with WebRecorder (which I think runs its own browser).
When MacroScheduler users IE7, the dialog appears.

I've added 'WaitWindowOpen', etc. to send keystrokes to close the window but they have no effect. The code executes when stepped through with the debugger but subsequently hangs (crashes) on the next

Code: Select all

'LibFunc>hIE,WaitIE,r,%IE[2]%'

line.

I can manually click on the 'yes' button to close the dialog but there is no further response from the script.

I believe similar behaviour has been seen before in topic 3247 (How to click ok button in web page) but the FormFill/Submit solution does not work here.

I've appened part of the script below. I'd be interested to know if there is a solution for IE7 (or if I am missing something obvious!).

Code: Select all

Let>FrameName={""}
Let>FormName={"frmLogin"}
Let>FieldName={"txtUsername"}
Let>FieldValue={"optimus"}
LibFunc>hIE,FormFill,r,%IE[2]%,str:FrameName,str:FormName,str:FieldName,str:FieldValue,0

Let>FrameName={""}
Let>FormName={"frmLogin"}
Let>FieldName={"txtPassword"}
Let>FieldValue={"xxxxxx"}

// removed clicktag call and added submit to this FormFill call
LibFunc>hIE,FormFill,r,%IE[2]%,str:FrameName,str:FormName,str:FieldName,str:FieldValue,submit

// added manually
Let>WW_TIMEOUT=5
WaitWindowOpen>Windows Internet Explorer
SetFocus>Windows Internet Explorer
Wait>1

// have also tried Press Enter
// Enter and Alt-y both work fine outside of script! 
Press ALT
Send>y
Wait>1
Release ALT

// script hangs here
LibFunc>hIE,WaitIE,r,%IE[2]%
Wait>delay

// commented out manually, why no %% around IE instance?
//libFunc>hIE,WaitNewIE,IE[3],0
//libFunc>hIE,WaitIE,r,IE[3]


LibFunc>hIE,WaitIE,r,%IE[3]%
Wait>delay

// form in new window
Let>FrameName={""}
Let>FormName={"frmSupplierAlertList"}
Let>TagValue={"btnContinue"}
LibFunc>hIE,ClickTag,r,%IE[3]%,str:FrameName,str:FormName,INPUT,NAME,str:TagValue

LibFunc>hIE,WaitIE,r,%IE[3]%
Wait>delay

[pgriffin]

Try the simple solution first. Look for a setting in IE to turn off the dialog warning you are getting.

[Optimus]

Try the simple solution first. Look for a setting in IE to turn off the dialog warning you are getting.

Yes, this was one of the first things I looked at.

I have had a closer look at the IE7 release notes (accessible from http://www.microsoft.com/windows/ie/sup ... fault.mspx) and they mention a change in the treatment of window.opener() and window.close() javascript, which may be related to this problem:

window.opener and window.close--Internet Explorer 7 no longer allows the window.opener trick to bypass the window.close prompt. Browser windows cannot close themselves unless the windows were created in script. This security enhancement no longer allows browsing to a random site when the main browser window closes unexpectedly.

I've also had a look
microsoft.public.internetexplorer.general and did a search for
webpage is trying to close window. There are two discussions which basically say this behaviour is by design and there is no way to switch it off. It is somewhat confusing as some folks claim the behaviour was also observed with IE6 and some claim that the dialog does not appear in IE7.
I'm surmising the differences are explained by the different ways the child windows can be created: there is not enough detail in most discussion items to discern the exact environments.

As a long shot, I've tried adding the web site I am trying to access to my list of trusted sites ( tools > internet options > security > trusted sites). No change. Problem persists.

So, if the dialog will always appear with IE7, I will need to rely on Macroscript to close it and move on.

Thanks.

[pgriffin]

hmm....If the window is JavaScript, you may need to use ImageRecognition to close it. With the window open, open ViewSystemWindows from the MacroScheduler menu and see what objects are accessible. My guess is that java has 'hidden' any buttons you might have expected to see.

If you haven't used ImageRecognition, just download it from MJTNET Downloads, Libraries and Plugins....

anything you don't understand from the examples, then just ask.

[Optimus]

hmm....If the window is JavaScript, you may need to use ImageRecognition to close it. With the window open, open ViewSystemWindows from the MacroScheduler menu and see what objects are accessible.

No, I'm almost certain the window is not a javascript alert box.
I don't believe ImageRecognition will help, unless you have an example for picking a 'yes' button off a Windows (ie system) dialog box.

Digging deeper ....
The client-side javascript tied to the form button calls a validate() method which simply returns true or false. If true, the forms post action is fired, which in this case is a call back to a ASP.NET page.

So what I think is happening is that the ASP.NET page is sending a window close instruction (presumably as javascript's window.close() method). This is captured by IE7's security logic which generates the warning dialog.

Here is the information from ViewSystemWindows for the dialog in question:

18809866 - #32770 "Windows Internet Explorer"
12125388 - Button "&Yes"
12256506 - Button "&No"
12715174 - Static ""
18940986 - Static "The webpage you are viewing is trying to close the window. Do you want to close this window?"


-----

More debugger info...

After I just step past the FormFill/submit call, the dialog appears. I manually close the dialog by clicking on the 'yes' button. The subsequent call to WaitWindowOpen/SetFocus on the just closed dialog generates a MacroScheduler warning that the desired window was not found.
So the macro seems to be finding the window okay, but it is the subsequent 'press enter' or 'press alt', send-y commands that are not being caught correctly.

-----

As an aside, I've tried using some competitors' products to see if they would shed any light on the problem.

Newbie Web Automation
Upon form submission, generates 'cannot get OLE handle for window' dialog. Closing the dialog generates a new dialog immediately. The only way to get rid of it is to kill the Newbie process through Windows task manager.

iOpus/iMacros
Has its own web browser. Upon form submission, the browser crashes and asks if I want to send a fault report to Microsoft.

[pgriffin]

I can certainly show you an application that will "pick off" any image you can see on the screen.

I always opt to use Image Recognition for most of an automated process because it removes most of these type issues.

Could you tell me a bit about your specific requirement? Personal use, Commercial use, etc... and what problem are you trying to solve?

[Optimus]

Solution:

LibFunc>hIE,FormFill,r,%IE[2]%,str:FrameName,str:FormName,str:FieldName,str:FieldValue,submit
Wait>delay

WaitWindowOpen>Windows Internet Explorer
Wait>delay
SetFocus>Windows Internet Explorer
Wait>delay
Press ENTER

This code will work if *not* stepped through with the debugger!
By not stepping, the focus will remain with the dialog and not return to the debugger. Sorry to waste everyone's time and effort.

The other requirement I found is that the dialog must be closed immediately after the formfill/submit.

Now onto my next problem ....

[Marcus Tettmar]

To make it work IN the debugger ensure you have Refocus Windows checked under Debug menu.