Well, I came across another Safari bug dealing with forms today. Unfortunately, I discovered this problem months ago and compeltely forgot it. So I figured I should document the issue so when it arises again, I won’t waste any time searching for the solution.

Basically, like most other issues with forms on IE and Safari, this issue deals with setting values of elements before they are on the document. Before today, I thought that checkboxes and radios in IE were the main problem, but textareas also have issues.

Here is the hack I did to solve the problem:

1
2
3
4
5
6
7
8
9
10

//While populating the form
var form = Element.createHtml('<form><textarea name="some_textarea"/></form>');
form.some_textarea.value =
    form.some_textarea._value = 'Hello world';
 
//When appending the form to the document
document.body.appendChild(form);
 
//Safari fix
form.some_textarea.value = form.some_textarea._value;

If I am feeling chipper, I may even search through WebKit’s huge list of bugs to see if it needs to be reported. Hope this helps someone out there.

In the world of rich web applications, browser bugs and incompatibilities are the number one killer of productivity, next to YouTube, Facebook, and Myspace. Like most web developers, I have come to realize most of those issues arise from IE and Safari. Today I stumbled upon another interesting problem when trying to implement some dynamic forms.

Take for instance the following code snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//Create form elements
var form1 = Element.create('form', {name: 'test_form'});
var input1 = Element.create('input', {type: 'text'});
var input2 = Element.create('input', {type: 'text', name: 'input2'});
 
//Append inputs to form
form1.appendChild(input1);
form1.appendChild(input2);
 
//Append form to document
document.body.appendChild(form1);
 
//Set input1's name
input1.name = "input1";
 
//Check if form picked up on name change
alert(form1.input1);
alert(form1.input2);

If you aren’t familiar with Prototype, this may be a bit hard to understand, but here is what is going on. I am creating a form with two inputs. Both inputs’ names are set in Javascript, but one is set before the form is appended to the document body, and the other is set after.

This code works fine in Firefox, but IE and Safari fail to note the name change, and don’t add the element’s property to the form element.

I created a workaround for a different Safari issue a few months ago, but it works well for this issue as well. The only requirement is your application must be using Prototype.

1
2
3
4
5
6
7
8
9

    Form.prepare = function(form){
        var elements = Form.getElements(form);
        for(var i=0, ii=elements.length; i++){
            var elm = elements[i];
            if(elm.name && !form[elm.name]){
                form[elm.name] = elm;
            }
        }
    }

In the above example, this would be called before we wished to access the form elements, alert(form1.input1).

Since Mike doesn’t really blog anymore, I figured I would steal his thunder and discuss some of his findings the past week.

For those of you that haven’t used Prototype before, it is a Javascript library which we use fairly heavily at webmail.  It has served us well for a while now …..

But version 1.5 is becoming too slow to be used in webmail. Being a very large web application, we don’t always have the luxury of elegant code, especially in javascript. Sometimes, we just have to do what works fastest and looks the ugliest. This past week Mike made some interesting findings, singling out some of the major performance culprits in Prototype.

Enumerable.each()

We have known this function is slow and have tried to avoid using it, but Prototype itself uses it on some very common functions such as:

• Element.addClassName()
• Element.removeClassName()
• Enumerable.* (Basically all of them use each() somewhere)

Mike overrode the first two functions to use a regular loop instead of each() and saw a 200ms login improvement! That is a pretty large improvement, nearly 14% of the total javascript rendering time on login.

Element.update()

For a long time, I thought Element.update() just abstracted element.innerHTML. I was wrong. It calls stripScripts() and evalScripts(). Since we never pass in text containing script tags, we overwrote this function to just use element.innerHTML. Again, another huge performance enhancement.

Unnecessary abstractions

Prototype has added some great functionality to javascript, but sometimes they take it a little too far with their abstractions. Some functions serve very little purpose other than to add an extra function call.

• Element.update() – Since we have taken out the stripScripts()/evalScripts(), there is really no reason to use this function
• Element.setStyle() – As long as you don’t set opacity or float styles, don’t use this function.
• Element.addClassName() – If you know an element doesn’t have the class name already, just call element.className += ‘ foobar’.