IE Corrupted Window/Desktop - Frameset and DHTML Menu

Poster: lrndhtml2
Dated: Wednesday August 9 2006 - 23:13:07 BST

Hello.

I have run into a strange corruption scenario with IE 5.5/6.0 on Win2K and WinXP (does not occur with Firefox 1.5/Netscape 7.2/Netscape 8.0/Mozilla 1.7). If anyone has any ideas or has heard of anything remotely similar please let me know.

The behaviour was noted in an application using DHTML Menu version 5.09 and now with 5.753, but is not consistently reproducible. Unfortunately the application is not externally accessible, so I cannot have other forum users examine it.

The application is frames-based with the following structure: 1 parent frameset (a) containg 2 child framesets. The first child frameset (b) contains two frames. The second child frameset (c) contains a frame and frameset (d) that itself contains two frames. A Java applet is being executed in the second frame of framset (b) as well.

The DHTML menu is rendered on pages displayed in the first frame of the utlimate child frameset (d). The two frames in it are set to scrolling="auto" and the bottom frame utilizes a frameborder (frameborder="yes").

When I move the frameborder separating the two frames vertically (especially when I move the border over the clipping area of the DHTML menu) it sometimes causes the entire screen rendering in Windows to go crazy. Lots of flashing elements, window boundaries completely gone, IE rendering over the entire screen in lopsided parts etc. Using CTRL-ALT-DEL to bring up the login security dialog and escaping from it refreshes the desktop so I can see window boundaries again. However if I move any elements of the browser window the crazy screen problems occur again.

Even if I close the frameset window other IE windows from the same process suffer minor rendering issues (even the dialog setting windows of IE don't render completely properly after this condition). Exiting IE and starting a new process clears up the problem. I originally thought it was isolated to a single machine (corrupted IE and/or video driver), but it has now been shown to occur on two other machines (both of which differ in video hardware/driver from the original "problem" device).

If I disable scripting in IE or comment out the loading of the DHTML menu the corruption does not occur. I thought that the auto-scrolling feature of DHTML might have been involved, but turning it off had no effect.

I have searched through the forums here and for general IE problems in various places but have not found anything that can explain what is going on here. It almost seems like the rendering engine in IE suffers corrupted geometry and then cannot recover. It is frustrating as the behaviour does not happen consistently - and my CSS/JavaScript/DOM knowledge is not sufficient for me to even guess why this weirdness appears IE-specific.

If anyone has any suggestions on what might be influencing this behaviour (CSS, etc.) I'd appreciate hearing about it.

Thanks in advance,

James.

Poster: John
Dated: Thursday August 10 2006 - 15:22:24 BST

James,

You're going to need to get something posted that we can take a look at. Trying to work this from just a description is going to be, I think, impossible. Get the site posted on an accessible server, post all the code here (don't forget to do so with the [code][/code] tags) - whatever. Also, stay away from 5.09. We can't even start to help unless you're running the current version.

Poster: lrndhtml2
Dated: Thursday August 10 2006 - 16:28:39 BST

Hello John.

Thanks for the response. I'm going to have to try and see if I can replicate it in a smaller test application as the application in question cannot be replicated internet-wise (policy, etc.).

While I am trying to do this I'd still be interested to hear if anyone ran into anything even remotely like this - it is definitely high on the strange meter.

James.

Some progress (potential solution - but still no explanation

Poster: lrndhtml2
Dated: Friday August 11 2006 - 17:11:23 BST

Hello.

I basically tore apart the frameset and started from scratch, and re-generated portions until the bad behaviour appeared again. What appears to be happening is an interaction between the frame containing the applets (which have no visuals embedded on the page, just the tag entries to allow launch - they are Swing based), a frame border and the DHTML menu.

If I disable the menu or disable the applets then the mysterious rendering issues do not seem to happen - the frame border can be moved without incident. If both are running then moving the frame border causes the render problem intermittently.

I also determined that when the rendering problem exists the "frame border" separating the display frames does not refresh while moving it via the mouse. With the applet or DHTML frame replaced by blank pages the frame border separater then refreshes as it is moved.

On a whim based on what I saw I experimented with changing the dimensions of the bordering frame elements to see what effect it had. When I reduced the height of the frame containing the applets so that its bottom terminated above the position of the frame border of the adjoining frameset - the rendering problems ceased.

All that I know at this point is that under certain circumstances the IE rendering engine and framesets containing a combination of DHTML and applets (maybe any ActiveX) are unhappy. Changing the geometry of the frameset elements appears to mitigate the problem. Unfortunately the circumstances are so specific I doubt many people will ever see it. I don't have IE 7 to look at to see if it happens there, but IE 5.5/6 both can suffer it.

So if anyone experiences anything remotely like this in the future - try adding/removing embedded elements to see if it helps or change the geometry of your frames.

James.

Poster: Ruth
Dated: Saturday August 12 2006 - 0:49:11 BST

Hi,

Thanks so much for taking the time to test this and provide all the information for a fix. I don't know that this will happen in the newest version since there has been much development and many fixes of various things, especially to do with applets, forms and such. But, we appreciate you posting your results, very much.

Ruth