IE8 beta2, contents of dialogs don't fill the width of the container

[Alfonso Martínez de Lizarrondo]

Sometimes works, and sometimes fails. And sometimes suddenly changes from one situation to the other while the dialog is open.

Check screenshot.

[Alfonso Martínez de Lizarrondo]

screenshot

[Alfonso Martínez de Lizarrondo]

It's really easy to trigger the bug, just hover the close button (top right) of the dialog and the content shrinks.

[Alfonso Martínez de Lizarrondo]

Seems fixed in IE8 RC1

[Alfonso Martínez de Lizarrondo]

I don't know what happened the other day, but the problem still exists.

[Paul Moers]

as a possible temporary workaround I tried <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> or <meta http-equiv="X-UA-Compatible" content="IE=7" /> but they don't seem to affect the dialog; or am I misunderstanding their purpose (clicking the compatibility view button does show the dialogs correctly)

[Paul Moers]

Two reasons seem to cause this:

• changing the background image of the closeButton when hovering it, the CSS rule #closeButton:hover

• and visualizing the ok button, the SetOkButton command. (I tried to use display:none and display: block, but this didn't work either.)

The first case can perhaps be solved by having a 16x16 px ison solely for the close button instead of a clipped strip. Didn't test this though as I have choosen for the easy evident solution, removing the hover style.

The ok button cause can be overcome by setting the dialog's size again after the ok button is visualized:

if (oEditor.FCKBrowserInfo.IsIE)
{
	dialog.SetAutoSize(true);
}

Or if this result in undesired size, you can set it manually:

if (oEditor.FCKBrowserInfo.IsIE)
{
	dialog.Sizer.ResizeDialog(widthPxValue, heightPxValue);
}

[Paul Moers]

hmmm seemingly you have to use SetAutoSize anyhow, also when you want to resize manually. Else the problem will remain. So do:

if (oEditor.FCKBrowserInfo.IsIE)
{
	dialog.SetAutoSize(true);
	dialog.Sizer.ResizeDialog(widthPxValue, heightPxValue);
}

[Paul Moers]

that appeared to not work properly when reopening the dialog.

By canceling out piece by piece of the dialog's CSS if found out that when the .contents CSS rule was removed, the problem disappeared. And when I put a width in there then too the problem was gone. Then I tried to set the width automatically in function InnerDialogLoaded:

if (FCKBrowserInfo.IsIE) $('contents').style.width = $('contents').offsetWidth + 'px';

But this resulted in a transparent empty dialog on some computers. I assumed that that was because the offsetWidth was not yet known so I built in a check on that:

if (FCKBrowserInfo.IsIE)
{
	setContentsWidth = function(){
		if ($('contents').offsetWidth > 0) $('contents').style.width = $('contents').offsetWidth + 'px';
		else setTimeout(setContentsWidth, 50);
	};
	setContentsWidth();
}

But still the dialog sometimes showed transparent. So although this did work on some computers, others showed a transparent dialog.

Setting the value to a fixed size did work, but that's only useful per plugin of course:

dialog.$('contents').style.width = '500px';

[Alfonso Martínez de Lizarrondo]

testcase

[Alfonso Martínez de Lizarrondo]

I've created a simplified testcase and filed ​https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=419515 as this is an IE8 bug.

[Alfonso Martínez de Lizarrondo]

Patch using X-UA-Compatible

[Alfonso Martínez de Lizarrondo]

If the bug isn't fixed in the final IE8 release, this patch takes care of it using the X-UA-Compatible header, but I'm not asking for review.

[Alfonso Martínez de Lizarrondo]

Good news: Microsoft has stated that the internal builds have fixed this bug, so this patch won't be needed.

I'll leave it open until the new build is released to make this easier to find and avoid dups.

[Alfonso Martínez de Lizarrondo]

The final release of IE8 works OK.