Lukav's Weblog

The latest discovery on IE problems was that when you use float divs and you decide to print, IE either ignore the floats or to be more precise, if you don’t explicitly specify width it just expands them to 100%.

There are some posts on the network, but all of them suggest to not use floats when printing. However this was no good for me, cause I arranged my forms with css and no tables. The solution to fix the width of floats was also no good, since I have different internationalization and some text differ in length.

So since I couldn’t find any css solution I had to make a simple JS hack.

In turns out IE has two useful events – onbeforeprint and onafterprint. So I just used those to go over all my floating elements and set the width before printing:

// We try to fix printing styles because IE is has problems
if (OAT.Browser.isIE) {
 OAT.Event.attach(window,"beforeprint",function() {
 	var elm = IB.PageContent.getElementsByTagName('div');
 	for (var i=0;i<elm.length;i++)
 		if (OAT.Dom.isClass(elm[i],'right') || OAT.Dom.isClass(elm[i],'left')) {
 			var size = OAT.Dom.getWH(elm[i]);
 			elm[i].style.width = size[0] + 'px';
 		}
 	}
 });
}

The example uses the OAT library, but you can guess what it does.

This fix works fine with the little exception that the divs move a little before print, but I can live with this for now.

For those of you that have discovered that when you have Firebug installed and are developing some synchronous XMLHttpRequest everything works, and when you disable it it stops: here is the problem.

Believe it or not it is a bug in Firefox NOT in Firebug. It turns out that Firefox doesn’t call onreadystatechange when the you set the 3 parameter (async) to false in open. Probably FF expects that when a call is synchronous the developer will process the result in the lines following the send call. May be this make sense, but if you want to quickly test async/sync calls or use a library that doesn’t take care of this, you be in trouble.

I can say for certain (I’ve committed the code myself) that the next release of OpenLink AJAX Toolkit won’t have this problem and will make no difference if you have Firebug or not.

I use the following to catch the situation where Firebug is not installed or is installed but disabled:

if (OAT.Browser.isGecko)
{
  try {
    if (!xhr.options.async && xhr.obj.onreadystatechange == null) {
      OAT.AJAX.response(xhr);
    }
  } catch (e) {
    if ((e.message && e.message == 'Permission denied to create wrapper for object of class UnnamedClass') ||
         e == 'Permission denied to create wrapper for object of class UnnamedClass')
      OAT.AJAX.response(xhr);
 }
}

OAT.Dom.isGecko() – return true if it mozilla and derivatives
OAT.AJAX.response – is the function that is normally called when the request finish.
xhr.options.async – is holding if the call is async or not
xhr.obj.onreadystatechange – is the original Firefox XMLHttpRequest object instance, since the code above works in the context of OAT