Strange IE7 behavior with JavaScript window.open()

Question

The following code was known to be working three weeks ago. In the interim we have installed IE 7 and a bunch of security patches. The ultimate question will be, does anyone know how to restore the old behavior?

Scenario

We have the following JavaScript code in web page 1 (let's call it foo.aspx), that is invoked on a button click:

window.open("http://Foo/App2/bar.aspx, "_blank", "titlebar,status,width=650,height=600");

The second web page (bar.aspx) is then supposed to open on top of foo.aspx. The user does some stuff, and when they click a button bar.aspx writes some values from bar.aspx back into fields on foo.aspx using JavaScript via window.opener.document, addressing each element individually and modifying its innerText. Then the user closes bar.aspx and there's foo.aspx where they left it, except now it has the values from bar.aspx in certain fields, and the user goes happily on their way using foo.aspx. This has been working for over two years.

During the last two weeks we've applied a bunch of security patches and upgraded to IE 7. Now the behavior is this:

1. If I am testing and simply navigate to foo.aspx directly, then upon clicking the button bar.aspx opens and then suddenly the focus switches back to foo.aspx with a popup dialog with "The webpage you are viewing is trying to close the window. Do you want to close this window? " If I choose "No", then foo.aspx stays alive, I have to Alt-Tab to get back to bar.aspx, and after that everything works as before. However, this is going to be a pain for the users. Note: NOWHERE IN foo.aspx NOR bar.aspx IS THERE A CALL TO THE close() METHOD!!! So I don't understand why the popup says what it says.

2. If I access foo.aspx via the application, which means it has been opened programmatically and not explicitly by the user, then bar.aspx opens and you can see foo.aspx disappear (close) behind it. Then bar.aspx gets JavaScript errors because the window.opener is no longer available.

Secenario #1 is non-optimal but at least would be a valid work around (if somewhat of a user training issue to train them to hit "No" and then Alt-Tab, where before none of this was happening. Scenario #2 is non-optimal in the extreme, given that the whole purpose of bar.aspx is to write those values back to foo.aspx.

Other things to note

1. Now that we've installed IE 7 and the subsequent Active Directory policy changes, the behavior is happening as described even on IE 6.

2. Both foo.aspx and bar.aspx run on the web server, on the same web site, but in different virtual directories. These are internal application accessible only from inside our network by authenticated users.

3. Having the server in Intranet zone (where it normally is) or in Trusted Sites makes no difference. I can see no settings in either Zone nor in Advanced Settings that would apply to this behavior, and both the Intranet and Trusted Sites zones are set to be extremely liberal in their policies, especially around script behavior.

4. I can make any changes I need to in bar.aspx and its client-side scripts, but am limited to only being able to change the button click JavaScript code in foo.aspx (that page is supplied by a vendor, whereas bar.aspx is internally developed).

5. I reiterate that other than the updates through window.opener.document, foo.aspx is not touched by bar.aspx, and certainly there is no attempt to invoke close() on it.

So, the question remains what in IE 7, or more likely in a security patch, would have broken this? We have a sister shop that is running the same code on IE 7 and they have not reported this issue. So it seems like it has to be something environmental, and right now I keep thinking it must be a patch that got applied. I would take a KB article, IE setting, registry hack, JavaScript change or anything else to fix this.

Thanks for any and all suggestions.

Answer 1

it might be a typo but there's a missing " after the bar.aspx in the sample code.

Answer 2

It is odd, first thing I would do is fix up a couple strange things in the code so far.

Use an absolute path such as "/App2/bar.aspx" without the protocol or server name since the apps are on the same server.

You can't actually control the titlebar or status bar outside the intranet zone so remove those values from the options list.

Answer 3

Is the pop up blocker closing the pop up window?

Answer 4

John, that was just a typo, but thanks.

Anthony, this app is in the intranet zone. That's probably an interesting thing to try.

epascarello, we have the pop-up blocker turned off for intranet and Trusted Sites zones.

Anyway, I finally figured out a way around it, so thanks for all the suggestions.

Answer 5

Opening a window programatically and setting the name to _blank, why are you doing that? I'm not saying that has anything to do with your issue, but it's probably not a good idea.

Answer 6

Hi This is Rehman