Again, it has been a while since I have blogged about anything but I came across something interesting the other day at work. To help you understand my problem I should give a little background about how my client’s system operates. They have a code base that is used for a few hundred front end sites. Since the code handles this many sites it has to be flexible enough to handle different types of input based on the information required for each site. For this post, lets assume that one site requires first and last name while some other site doesn’t. What the code will do when a form is submitted is see if first and last name are part of the values submitted and if they are, makes sure validation is run on those fields to make sure they have values in them. If they are not there then the site assumed they are not required and validation is not done on those fields.
To the problem I was trying to solve. The site I was looking into had some Ajax stuff that would find an address based on zip code and house number and return the results into a drop down for you to select. Once you selected a drop down and clicked a button the address fields that were in a hidden div would be filled in a the div would be displayed. While hidden, this div with the address information was also being disabled by having the disabled attribute added to it. Read that last sentence carefully as it is the entire point of this post.
Normally I would assume a disabled div is nothing to worry about, but what was happening is that when Internet Explorer users would search for an address but not explicitly select one from the drop down, the address div remained hidden and disabled when the form was submitted. This was causing unexpected behavior on the page because things that were suppose to be there and be validated were assumed to not be required and the rather than return the validation errors the page continued executing, throwing an errors farther down the pipeline.
As I mentioned before the problem had to do with the div that contained the address inputs being disabled. When run in Firefox and Chrome, the page behaved as expected and this error was limited to Internet Explorer. I should note that I am using the latest versions of each browser. At first I didn’t know where to start and it was only after discovering the script used to do the address lookup did I find what I needed. I noticed that after each step it was disabling and hiding the divs that were not part of the current step. I thought this might be the problem so I set up a simple test to test my theory. I created a simple Asp.Net project and created the markup below inside the form tag.
1: <div disabled>
2: <table border="0" cellpadding="0" cellspacing="0">
5: First Name:
8: <input name="txtFirstName" type="text" />
13: Last Name:
16: <input name="txtLastName" type="text" />
21: <asp:Button ID="btnSubmit" Text="Submit" runat="server"
22: onclick="btnSubmit_Click" />
I then added a breakpoint inside the click event of the button to see how many values came up with the form. Even though the div is disabled you can still type into the textboxes. When I submitted the browser in IE, first and last name were not there. When I submitted it in Chrome and Firefox, the values were there. As it turns out, according to the W3C, divs are not valid elements to be disabled and the default behavior for inputs that are disabled is for their values to not be submitted with the form. Since they were not generating valid HTML I assume it was up to each browser how they wanted to handle it. IE decided to not submit the values since they were in a disabled element and Chrome and Firefox decided to submit them since the inputs themselves were not disabled. While this is not something you should ever have to worry about if you generate valid HTML I still think it is interesting and maybe something worth knowing.