I'm attaching a modified version of TestOpenInTargetFrame that reproduces this bug. TestOpenInTargetFrame has two frames, left and right; in the right frame, there's a link whose "target" attribute is leftFrame; it verifies that the leftFrame loads the correct page.

In my modified version, it first opens Frames.html, selects a subframe, and then runs TestOpenInTargetFrame. This doesn't work because we aren't able to track down "leftFrame"; we incorrectly report "Window does not exist".

There's a simple workaround for this, which is to run openWindow("", "leftFrame") right before you click on the evil link.

There's a variety of possible fixes for this, some more invasive than others. One fix (not particularly invasive) is to change _modifyWindow to make it add win.name to this.openedWindows, so it can be tracked/identified later. This doesn't quite fix the test, but it makes it possible to workaround it: you need to select the left frame first, then select the right frame and click on the link; now the leftFrame is recognized (we've seen it before) and the test passes.

Another fix might be to call openWindow("", "leftFrame") pre-emptively just before we do the click. The trouble is, that trick works great when the relevant window/frame is already open, but pops-open a window when the frame doesn't exist, which is probably not what anybody wants/expects. (Can we do it anyway when clicking on a target link?)

Another thing we might do (again in _modifyWindow, presumably) would be to search down through the entire frame/subframe tree looking for windows and adding them to this.openedWindows. (In a try/catch block, presumably, because we might get Permission Denied or other troubles in our search.) Presuming the search worked, this would fix the bug, but it might have an impact on performance, and you can bet it would take a while to iron out properly.