window.opener.document.form1.textbox1.value = “hello world!”
They saw this statement fail, and doesn’t update the value. While debugging this (via IE’s supercool developer tools F12), found that the “form1” specified is undefined. We are sure that there is a form in the page1 that opened this page2. If we look at the HTML output sent by the server, we saw the below:
<form method=”post” id=”form1”> </form>
Issue started for them where the same code was working on one server, and the same was failing in other server. I manually compared the code, and there is absolutely no difference between the servers. Both the websites run in ASP.NET 4.0. But, yes – there got to be something different between the servers right?
It was found to be with the web.config files, I never got access to their web.config files earlier, so I couldn’t do a simple diff on them to find something has changed. Rather, thought about few things which would be causing the addition of “name” attribute in the <form> tag. And, it was xhtmlConformance tag set the mode to “Legacy” on one server, and not set on the other one (failing one). So what this setting really do? Take a look at this article which briefs a few things on XHTML standards, and ASP.NET.
The name attribute on the form element is not allowed in XHTML 1.1 guidelines. You can configure your application not to render a name attribute.
ASP.NET 4.0 by default doesn’t create the name attribute for the form element, and that created the problem to this project my customer was working on. We generally do not recommend setting the xhtmlConformance mode as “Legacy”, since it would not force the server tags to be standards compliance. Although it can work well with your websites, you can consider changing it to “Strict” or “Transitional” as per the requirement. You can read more about this setting in this blog of ScottGu.