IE Performance Issues Adding Dom Nodes

October 12, 2009

My app has a search screen that fetches the results via Ajax and displays them in a table. Worked fine in Firefox, but in IE there’s a slight processor jump for a second or so. Strange, but not a problem. The users of this app, however, use a remote desktop app to run IE to access it. And when they did the search, their CPU would hit 100% for 1-5 minutes, making the entire terminal completely unusable.

I agonized over different JavaScript fixes: removed a table JS widget, switched off of tables altogether, switched to innerHTML, used DocumentFragments. Nothing worked.

Then, on a whim, I disabled all the CSS files on the app, and it worked like a charm. As I narrowed it down, I discovered that some CSS I was using to emulate frames (non-scrolling header, footer, and sidebar) was the offending code.

Let’s step back and think about that one again. What caused the processor to hit 100% for 5 minutes was not JavaScript, but CSS.

Sigh. So, if you have an issue with IE hitting 100% processor load for any reason, don’t assume that JS is necessarily the problem. Try disabling your CSS and see if that fixes it.

Submit Buttons and Ajax

April 10, 2009

We’re writing an Ajax webapp with progressive enhancement. In other words, if JavaScript is disabled, it should work – but if JavaScript is enabled, it should work better. As a general pattern, then, all of the buttons in our app are submit buttons that execute server-side behavior. When the page loads, we attach click event listeners to the buttons, to call the appropriate JavaScript methods.

By default, though, the submit buttons still try to submit the form. But we need to disable that, so that only the Ajax call happens. The first solution I tried was:

document.getElementById("myform").onsubmit=function(){return false;};

This disabled form submission altogether, which worked just fine.

The problem arose when we had a form that had to have some submit buttons work, but not all. It’s a shopping cart page, and we want “Checkout” to still submit the form and go to the checkout page; but we want the “Remove” buttons to execute Ajax calls to remove elements. They’re all in the same form, because, for example, if the user updates a quantity for one product, then removes another product, they expect the quantity change to be saved as well. So one big form.

The best solution I found for this was to actually create a new button-button, and use it to replace the submit button. At first, this seemed a bit clunky. But the problem is that the submit button wants to submit the form, and I was having trouble finding a way to prevent it from submitting. Rather than messing with its internals, it’s cleaner to create a button-button, that doesn’t want to submit.

IE6 setAttribute “onclick” not working

October 16, 2008

OK, I don’t have time to fully test this one, but when I dynamically create DOM nodes in a YUI panel, and then create an anchor tag and add an onclick handler to it (no HREF) by using setAttribute, IE6 doesn’t register the click event. It seems that I need to use another event attaching method, like YUI Event addListener() – that works fine in both IE and FF.

Multiple YUI Modal Panels

October 9, 2008

Creating a page with several different modal YUI panels (popup “windows”). Some of the modals were showing up behind the overlay that shades and disables the rest of the page.

When I looked at the DOM, it turns out that I didn’t properly close some tags, so some of the modals were actually inside┬áthe other modals. Any time a YUI panel isn’t a child of the body element, that can cause problems with modality. Fixing the closing tags fixed it.