The return of Modal dialogs in ActiveX controls hosted by Internet Explorer 8 ( IE8 )

When IE8 was released I was asked to do some evaluation of our somewhat large ActiveX application to see what issues to expect. The single largest issue was the fact that suddenly none of our modal dialogs were modal any longer! Now depending on your design, this new behaviour could be disastrous (and it would have been for us). Fortunately there is a registry setting to make IE8 work as it does in IE7 and previous versions:

HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\

TabProcGrowth = 0

The value name can be a DWORD or a string (but my example assume a DWORD).

for more info on this setting and what it does check out search for the word TabProcGrowth.


2 Responses to The return of Modal dialogs in ActiveX controls hosted by Internet Explorer 8 ( IE8 )

  1. We noticed the same thing. In our case (ActiveX built in Borland Delphi 7), an error message is generated when the user navigates away from the page (say by hitting the back button) and the modal window becomes “orphaned”, and attempts to close it display error messages and the close attempt fails – as expected.

    But, now hit the forward button and navigate back to the page, and something strange happens: The browser reconnects to the session – displays the embedded page (without displaying a new login window), and restablishes the session. The already open modal window can now be closed without error.

    Even stranger, although the modal window does not display the previously displayed record when the session re-establishes, we can hit the find button on the window, which then correctly displays the records in our filter and reestablishes the correct display record. Obviously this has something to do with how we are handling the client to app server comms (we recently put some code in to handle broken connections – so I suspect that that is getting involved in this – but there are other warning messages we should get in this case that we do not).

    Heaven only knows how IE is doing this, since the server sessions are dcom objects where currency and maintenance of state is critical, and the dcom server closes down when the connection is lost! At the very least it is somehow reconnecting the “modal” window to the new activeX session – which doesn’t make sense to me at all.

    This behaviour was obvserved on IE8 on XP. Haven’t checked the behavious in Vista or Win7 yet (our vista machines have IE7 and the Win7 RC test machine has issues with one of the windows in the active X so we have to solve that first). Interestingly, Win 7 has no problems with that window when the app is not deployed as in activex embedded in IE 8, nor does XP with IE 8 have any problems with the same ActiveX on any window.

    There is possibly another way to trigger the IE 7 compatible behaviour in IE 8 – that doesn’t involve writing to the registry. For HTML/CSS we can use (must be the first thing on the page):

    But that doesn’t seem to solve the ActiveX problem, although I did note after I put this in that after child windows launched a modal window the new window was modal with respect to the immediate parent (ie. modal grand children were modal with respect to the modal child) and that modal children were modal with respect to eachother – but not with respect to the browser or the embedded ActiveX parent.

    Also – you can not close IE 8 whilever there is a “modal” window open.

    However it is a really big mess regardless. Heaven knows why MS keep messing with the ActiveX’s like this, when all they really needed to do was make absolutely certain a user could not install or update one without knowing and agreeing. Alternatively, they could have given us a sandbox mode, where an activeX that agrees to be 100% contained in a sandbox was treated as otherwise trusted (because it could only read and write to its sandbox registry and disk area, and maybe read certain restricted system areas). Although using MS Office spell checking could then be a problem.

    One improvement in IE8 in Win 7 versus IE7 in vista is the way an activeX with an embedded browser now behaves. SInce IE8 – at least on Win 7 – has intranet mode disabled by default, all pages are treated as internet zone pages, so embedded browsers no longer open in out of process sessions like they did in IE7 on Vista. Of course this will have other consequences, but at least it stops the ugly popping browsers when the activex page was served initially from an intranet web site.

    In your investogations, did you discover how to tell what zone the browser thinks it is currently in from an activeX embedded in it? I could not find that anywhere.

  2. Previous post lost its tag example so I am putting it in this one: