IE Performance Issues Adding Dom Nodes

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.

CXF JAXWS Client Returning Null

We’re using CXF to generate both our web service and client. For a certain method call, the web service was returning the correct XML (we used tcpmon to make sure of this), but the CXF client was returning null to our code, instead of the returned objects. Other web service methods were returning data correctly, however.

After some research we discovered a difference between the WSDLs for the two method calls. Here’s the correct one:

<xsd:complexType name=”getAllCategoriesResponse”>
<xsd:sequence>
<xsd:element minOccurs=”0″ name=”return” nillable=”true” type=”ns1:ArrayOfCategory”></xsd:element>
</xsd:sequence>
</xsd:complexType>

And here’s the incorrect one:

<xsd:complexType name=”loginResponse”>
<xsd:sequence>
<xsd:element minOccurs=”0″ name=”User” nillable=”true” type=”ns1:User”></xsd:element>
</xsd:sequence>
</xsd:complexType>

Note that the correct xsd:element has a name of “return,” but the incorrect one has a name of “User.” For some reason, the CXF client ignores returned data unless its name is “return”. When we switched “User” to “return,” it worked fine.

If any readers have details on why this is the case, or other light to shed on the issue, please comment. Thanks!

Top Reasons Your YUI Widget Looks Messed Up

1. You created the widget but didn’t call its render() method. When you create it, that seems to update some styles and DOM elements, but not all. Calling render() updates the rest.
2. You tried to apply the widget to multiple elements, but, since they have the same ID, it was applied to the same element multiple times. This is like the Ghostbusters crossing the streams, and is very bad.

IE6 JavaScript error: “Expected identifier, string, or number”

Note to self: if your code works in FF, but  you get the “Expected identifier, string, or number” error in IE6, this is probably caused by having a list with a comma after the last item. Remove the extraneous comma, and it should work.

Submit Buttons and Ajax

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.

Flash Movie Dotted Border in FF3 Win

In Firefox 3 on Windows, a Flash movie had a black-and-white dotted border when clicked upon.

Turns out that this is because it has a default “outline” style in FF3. Style it to “outline:none” and you should be fine.

Better solution: use a CSS Reset =]

YUI Calendar Changes Dates

My Ajax app has a persistent date it keeps track of, to compare other dates against. But I ran into a problem where the date was somehow being changed – from 12am on a certain day to 12pm. I looked through my code, and I wasn’t even changing it anywhere.

Finally, I noticed I was passing the date into a YUI Calendar object, to specify what was the minimum allowable selectable date. JavaScript Date objects are mutable, so I realized it was possible YUI was changing the hour value on the date. Sure enough, when I changed the code to pass YUI a copy of the Date instead, the date’s hour was no longer changed.

I’m still not entirely sure why YUI would need to change the Date, or if it’s even good design for it to do so instead of creating a copy of the Date object. Nonetheless, lesson learned: if you want to make sure an object you’re passing somewhere is unchanged, make a copy before you pass it. This smacks of a general OO principle, but for some reason I haven’t run across this problem in the Java world before.

News Flash: IE getElementById Invaded By Form Field Names!

If document.getElementById() isn’t returning the results in IE that you expect, checkand see if you have any form fields with that name. It seems like IE returns them from getElementById() – even if you manually give them an ID different from the name, that doesn’t conflict! Your only hope seems to be renaming the element you need to select, so that it doesn’t have the same name as any of your form fields.

IE6 setAttribute “onclick” not working

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.

IE6 :hover Support

IE6 does not support :hover pseudo-classes on non-anchor elements. Ugh.

There are a few fixes out there. This one uses prototype. I was able to translate it to use YUI Event and Dom pretty easily. Wish I had an open-source agreement with my employer so I could show it here.