Posts tagged javascript

Dynamic enum fields in nested association forms in Rails Admin


We’ve had a few projects at Panoptic Development recently that made use of the RailsAdmin gem. Out of the box, RA satisfied about 95% of what we needed to do to complete each project, but there were a few edge requirements that we either had to make do without or find workarounds for. Don’t get me wrong, RA is a wonderful utility for quickly spinning up an administrative area for your Rails app. It’s loaded with really slick bells-and-whistles, and it has an incredibly flexible DSL for configuration. However, there are a few things it just doesn’t seem to be able to handle as-is and for which I’ve searched high and low for solutions for the last 9 months. I’m happy to report that I finally cracked one of these problems, and it wasn’t even all that complicated in the end.


A note about synchronous xmlhttp requests and Firefox


Since I just spent the better part of Friday debugging this problem and then the better part of Friday night Googling for a work around, it’s worth noting that there is a “bug” in the Firefox implementation of the xmlHTTPRequest object when using it for synchronous calls (i.e. the rest of the script pauses and waits for the request to complete, unlike typical asynchronous AJAX calls). When using the xmlhttp object in a synchronous fashion, Firefox does not process the onreadystatechange handler. Thus, any libraries that are dependent on this (for running post processing functions for example) will fail to work under these conditions. Interestingly, having the Firebug extension installed causes the object to behave properly. So a secondary note is to always test your apps in a “clean” instance of Firefox.

Here are the details that I came across, along with a work around: Lukav’s Weblog » Blog Archive » Firefox firebug and synchronos calls problem.

I’ve also set up a set of tests to demonstrate the problem. Try in both Firefox and IE to see the differences.

* This post was originally published on June 5, 2007 at

IE getElementById Bug Strikes Again


I was burned by the document.getElementById() may return incorrect element in IE and Opera bug again today. This time though it was particularly bothersome as I spent the better part of the afternoon trying to figure out why I couldn’t access the length property of the value of a textarea element in IE when the same code worked fine in Firefox. I mean, getting the length of a value of any form element through JavaScript usually isn’t like rocket science.

<textarea id="description" name="description">Here is some text</textarea>

<script type="text/javascript">
var myElement = document.getElementById('description');
alert(myElement.value.length); //alert: 17

Every time I tried to execute that code in IE it would complain that 'value.length' is null or not an object.

After a whole crap load of debugging I finally tracked it down to the fact that IE was actually referencing the <meta name=”description”> tag in the head section of the page. Yeah, see even though the function is getElementById, IE still thought I meant the element with the name attribute equal to “description”. Or as my brother put it in a comment to the original post (before the comments were wiped in the great Data Loss of ’06), maybe IE thought I was calling the getJustAboutAnythingIFeelLike() function…

Damn you IE for making me have to change my ID attributes to suite your leisurely implementation of the DOM!

* This post was originally published on April 5, 2007 at

Dear Ecma, how about standardizing your date functions, eh?


Dear Ecma,

I would just like to point out how completely asinine your JavaScript Date object implementation is. How did so many of it’s member functions come to operate in such a non-intuitive way in relation to each other?

Why does getDate() return the day of the month instead of the date itself, while getDay() returns the day of the week and not the day of the month?

Why does getMonth() return a value from 0-11, but getDate() returns a value from 1-31?

Do you know how utterly confusing that is???


* This post was originally published on March 22, 2007 at

document.getElementById() may return incorrect element in IE and Opera


I came across a bug in Internet Explorer whereby the document.getElementById() function may return an element with a name attribute equal to the id that is specified. This can cause unexpected results.

According to the W3C’s DOM Level 2 Core Specification:

getElementById introduced in DOM Level 2
Returns the Element whose ID is given by elementId. If no such element exists, returns null. Behavior is not defined if more than one element has this ID.

Note: The DOM implementation must have information that says which attributes are of type ID. Attributes with the name “ID” are not of type ID unless so defined. Implementations that do not know whether attributes are of type ID or not are expected to return null.


elementId of type DOMString
The unique id value for an element.

Return Value

ElementThe matching element.

No Exceptions

However, for the browsers that failed the test, it appears that their implimentation of getElementById returns the first element where the ID or name attribute is equal to the specified ID.

This bug was tested against the following browsers:

  • IE 6.0 sp2: failed
  • IE 5.5: failed
  • IE 5.01: failed
  • Netscape 7.2: passed
  • Netscape 6: passed
  • Mozilla 1.7.3: passed
  • Opera 8.2: failed
  • Firefox 1.0.6: passed

For instance, the following code should produce an alert with “foo=foo; bar=bar”. However, the browsers that fail the test actually return “foo=foo; bar=foo”.

Test Page

Reported at 2005-08-29

Noted on

* This post was originally published on August 29, 2005 at

Go to Top