Tag Archives: IE

Trick IE into reserving a connection for Comet traffic

“Comet” is a dhtml technique for sending updates from the server to a browser client. One way to do it is to place a hidden iframe in one’s page and have the server write a <script> to the response whenever there’s an update; the script executes as soon as the client receives it, and it might popout a window containing a new message or change styling in the parent doc. In order for the client to keep getting updates, the server purposely never indicates that it has finished writing the response.

A webapp that uses Comet typically needs one connection for Comet and one to send requests to the server whenever the user makes some kind of edit (aka RPC = remote procedure call).  While the second connection isn’t needed all the time, IE6 permits only two connections to be used at any time, so any other windows open in IE have to fight with your service for them, which sometimes leads IE to close one of your connections prematurely.

Although it’s not friendly to such other services, one can trick IE into reserving one of its connections for your Comet page by requesting that page from a different domain than one makes RPCs from. If the server must maintain state, the domains can even point to the same machine (although you probably need to map both domains to a switch that then uses a cookie to find the particular machine)

To simulate such a setup on a Window dev machine, add the following line to C:WINDOWSsystem32driversetchosts

127.0.0.1       fake-domain1                       fake-domain2

IE6 doesn’t support onclick handlers for

Instead, you have to use an onchange handler in the SELECT, like this:

<html>
<head>
<script>
function fAlertA() { alert(‘A’); }
function fAlertB() { alert(‘B’); }
function fHandleActionSelection(nSelect)
{
var iOptionIndex = nSelect.selectedIndex;
if (iOptionIndex > 0) { //skip over ‘Actions’
var sFnName = nSelect.options[iOptionIndex].value;
eval(sFnName+”()”);
}
}
</script>
</head>
<body>
<select onchange=”fHandleActionSelection(this)”>
<option>Actions</option>
<option value=”fAlertA”>a</option>
<option value=”fAlertB”>b</option>
</select>
</body>
</html>

“Internet Explorer cannot open the Internet site…Operation aborted”

There was another problem that just appeared today where IE was popping an error saying “Internet Explorer cannot open the Internet site…Operation aborted”. Web search indicated people saw a similar problem when using the Google Maps API, evidently because IE doesn’t like scripted changes to a table DOM before the rendering finishes:

http://vidmar.net/weblog/archive/2005/08/22/2121.aspx

http://www.ryangrant.net/archives/internet-explorer-cannot-open-the-internet-site-operation-aborted-google-map-api

The suggested change was to wrap the JS inside a setTimeout with wait of 1ms. That worked for me.

Unspecified error for createStyleSheet()

Our rich text editor (RTE) was working in IE just yesterday, at least from my dev server. But once installed in QA, a JS error was being popped whenever the Compose page loaded, and the error indicated M$ method createStyleSheet(), which is called on the RTE iframe’s doc object. If one takes the option to debug offered by the error popup, VisualStudio can only say “unspecified error”, but then the RTE becomes usable!

This suggested a timing problem, and sure enough, a web search turned up problems if one calls createStyleSheet() before the doc obj’s readyState property reaches “complete”:

http://dojotoolkit.org/pipermail/dojo-interest/2006-May/008587.html

To workaround this, one could just keep trying:

function foo (sCssPath) {

try {

eDoc.createStyleSheet(sCssPath);

} catch() {

setTimeout(“foo(‘”+sCssPath+”‘)”, 10);

}

}

But that runs the risk of looping forever. A better way might be to use the M$-only onReadyStateChange handler:

if (bIE) {

if (eDoc.readyState == “complete”) {

eDoc.createStyleSheet(sCssPath);

} else {

eDoc.onreadystatechange = function() {

if (eDoc.readyState == “complete”) {

eDoc.createStyleSheet(sCssPath);

}

};

}

}

Details at MSDN

IEDeveloperToolbar almost as useful as Firebug

I was just told that there’s an IE Developer Toolbar:
http://www.windowsmarketplace.com/details.aspx?view=info&itemid=2695980

At first glance, it provides a significant fraction of the utility of Firebug, such as showing DOM structure changes post-load. It also has a “Trace Style” feature, evidently for revealing the cascade of styles that apply to a particular element, but when I tried it all it did was open a window displaying my stylesheet.

It does not appear to support live editing of markup or styles.

IE JS doesn’t support indexOf() for arrays

Firefox supports indexOf() for arrays, but IE doesn’t (at least IE7 doesn’t). To work around this, write your own version…maybe like this:

function fiArrayContains(ax, xTarget) {

var n;
if (fbIsArray(ax)) {

n = ax.length;
for (i=0; i < n; i++) {

if (ax[i] == xTarget) {

return i;

}

}

}
return -1;

}

function fbIsArray(x) {

return fbIsObject(x) && x.constructor == Array;

}
function fbIsObject(x) {

return (typeof x == ‘object’ && !!x) || fbIsFunction(x);

}
function fbIsFunction(x) {

return typeof x == ‘function’;

}