Background (my questions follow this long-winded section!)
----------

A while back, using Silk 2.1.4, I had a lot of trouble with
a web application which spawned a 2nd browser window in
response to normal user selections. As long as a testcase
terminated without error, I was then able to set the 2nd browser
window active using its page name, such as foo.SetActive(),
I was then able to reliably terminate the window with a
Browser.Close() method.

At that point my original browser window (which contains
https login session information, which I refer to as my
1st "logical" browser window) was intact and ready
for the next testcase.

Problems though occurred if the testcase encountered
an exception and terminated without executing the
exit code that understood both browser window
page names. In this error exit situation:

1. Silk's default recovery system sometimes correctly closed
the 2nd (logical) browser window; sometimes incorrectly
closed the 1st (logical) browser window; and often closed
both windows!

After much evaluation I discovered that whichever browser
window is active is considered as [Browser]#1, while the
inactive browser window is considered [Browser]#2. Therefore
trying to rely on the Browser.CloseOthers() method, invoked
deep in Silks builtin recovery system, proved to be
unreliable.

2. I then took over TestCaseExit() and wrote a routine
which, when it determined there was more than one browser
running, attempted to walk "Back" though each page in
the currently active browser looking for the login page--
if it is found then the "other" browser is killed off, else
this browser is killed off.

This approach mostly worked; except in those ugly situations
where one of the browsers is "not ready"--which then cascades
into countless timeout error conditions. This is also a
fairly complex function to keep working correctly, as new
error exit conditions are encountered.

3. Ultimately the developer agreed (based on customer feedback)
to eliminate the 2nd browser window and run the entire
application in the context of a single browser window.


Questions
---------

1. Is anyone testing a web application which spawns multiple
browser windows, using Silk 5.0? If you are, can you count
on the builtin default recovery system to correctly close
the (logically) 2nd window? (I think not, based on my
evaluation today with the Window Declaration Recorder with
a new app which spawns two windows).

2. If you have a web application of this nature, and are using
Silk 5.0, and have had to code your own custom recovery
mechanism, what technique do you use to reliably close
the 2nd [3rd/4th/etc.] spawned browser window, when a
testcase prematurely terminates with an exception, leaving
all browser windows open?

3. To all: is it considered a "good" practice to write web
applications which spawn multiple windows? Not only do I
find this to be testing problem, but I also find it confusing
to try and use an application which does this (especially those
which spawn 3 or more windows). Can anyone point me to a UI
design article which addresses this issue?


-Thanks, Terry Horwath
The Carl Group
thorwath@pacbell.net