The Puerto Rican Rails Dude

One of the not-so-joyous moments of being a web developer is the fact that we still need to support browsers that are ancient (by technological standards). Specifically, I’m talking about Internet Explorer 6.0. A quick look at the site statistics of one of the major websites I’m currently working on says that 16.9% of users visited our site using Internet Explorer 6.0. That’s obviously not the majority - Internet Explorer 7.0 takes that honor with 38.4%, followed by Firefox 3.0 with 19.8%. But it’s still a large enough number for the higher-ups to decide not to ignore it.

Since I never, ever use Internet Explorer 6.0 for any regular browsing (and you shouldn’t, either - read why on sites like Browse Happy), this past week I decided to give the site a test run with Internet Explorer 6.0 (using IEs 4 Linux). Besides the frustration of finding some incompatibilities with standard CSS on this browser, everything else seemed to work well. I then triggered an error on purpose, just to make sure our error handling would be handled properly (display our custom 404 error page instead of a nasty -yet customized - 500 error page). To my surprise, Internet Explorer 6.0 decided to render its own friendly error page instead of our custom one.

Thinking one of my colleagues removed it for whatever reason, I fired up Firefox and triggered the same error. The custom 404 page appeared correctly. Heading over to a Windows laptop, I had the custom error page on all browsers, including Internet Explorer 7.0. This left me scratching my head for a while. Although I’m already used to Internet Explorer 6.0 to act in different ways, standards be damned, this act seemed to be stupefying.

I was about to give up, thinking that Internet Explorer 6.0 used to hijack everyone’s custom error page just to hawk their own, I did a search on 404 error pages. Lo and behold, Wikipedia came through with a response that I would have never guessed:

Internet Explorer (before Internet Explorer 7), however, will not display custom pages unless they are larger than 512 bytes, opting to instead display a “friendly” error page.

Wow. Who knew that size mattered? On a custom error page, of course.

Our custom 404 was basically just a regular HTML with the standard tags, and one image and it weighed less than 300 bytes. I couldn’t modify the design or anything, so I just padded the error page with a long, boring and senseless comment, explaining why said comment was there. After ‘fattening up’ the file to more than 512 bytes, the error page started appearing on Internet Explorer 6.0.

It turns out that older versions of Internet Explorer had a threshold value in the registry which decided whether to display their own error page or a custom one. Why? I have no idea. Thankfully that was fixed for recent versions. But for all of the unlucky ones who still have to support ancient technology, this is another special Internet Explorer 6.0 quirk that needs to be taken into consideration.

For more information, including the default size limitations for other error pages, read this site (aptly named ‘404-error-pages.com’) has all the information you need.

Today I had a pretty frustrating moment. I made some new changes in the morning, which included the addition of a new column in the database. This field wasn’t required, but I needed to limit the amount of characters a user could enter in that string. So I did the proper thing and set this in my model:

validates_length_of :locations, :maximum => 200

I did a quick test, and the validations worked great. So I promptly committed the code to our repository. A few minutes later, our Continuous Integration system sent me a nasty E-Mail: I broke the build.

I frantically searched the errors in the test, and it seemed that the tests were expecting that field I just added to have something. I was stumped, thinking that unless you specify validates_presence_of, set a range of characters in the validates_length_of or perhaps some regular expression validations in the model, that would be the only time a model would require the field to be there. I hadn’t done any of these.

Frustrated, I added a simple string to the fixtures and the test code for this field, and the tests passed. Not content in just making something work, I needed to know what was up. So I started digging around, and found something that now seems obvious, but I totally ignored before.

Whenever you submit a form for a model in Rails to insert a new record in an ActiveRecord model, all the fields you have set in the view are passed in the POST request. However, if you didn’t enter anything in a field, the parameters for that field would simply be sent blank. In this case, validates_length_of doesn’t bitch about the missing field, because it’s there. As long as the number of characters - in this case, zero - isn’t more than what I specified in the model, it’s all good. However, the tests were failing because since I hadn’t specified that new field in the fixtures, the parameters were sending that field as nil, which caused the previously mentioned validation to scream out.

So just as a quick review:

• validates_length_of - Verifies if the field is within the amount of characters specified in the validation code. If no minimum is set, it won’t mind blank fields, but it will mind nil fields.
• validates_presence_of - Verifies if the field is nil or blank.

Like I said, it’s obvious now, but not so much when I was getting alerts that the build failed for some silly reason.

Today I noticed that whenever using some of the Prototype Helpers in Rails (such as link_to_remote or remote_function), it was setting by default the evalScripts parameter to true. For those who don’t know, Prototype uses evalScripts to evaluate anything in <script> tags from the response text. This was giving me major headaches in a piece of code today.

Looking at the previously-linked API page for the Prototype Helpers, there was no mention on how to set this parameter to false. I thought that simply passing :evalScripts => false as an option to the helper would do the trick, but it didn’t. So I had to dig into Rails source code to see if there was any way to set this to false.

When reading the prototype_helper.rb file, which houses the helpers that generate the HTML / JavaScript code, I noticed that there’s an option named :script that allows the developer to set the value of the evalScripts parameters in the generated JavaScript code.

In short, passing :script => false as an option to your Prototype Helper code on the view will correctly set the evalScripts parameter to false.

Hope this helps someone!