8

Closed

Input controls with HTML5 types do not post back in Firefox, Chrome, Safari

description

In August 2011 Microsoft released the "Microsoft .NET Framework 4 Reliability Update 1" (http://support.microsoft.com/kb/2533523) which amongst other things fixes two issues with the UpdatePanel control when using the new HTML5 input types such as "tel", "email" etc.

MicrosoftAjaxWebForms.js was updated as part of Reliability Update 1.

Unfortunately, because the Ajax Control Toolkit uses a forked version of several JavaScript files including MicrosoftAjaxWebForms.js, the version that is included with the Toolkit overrides the "standard" version of the .js file that includes the fix.

The result is that when you have an input control that uses one of the new HTML5 types e.g. <asp:TextBox ID="txtTelNo" type="tel" runat="server" /> and this is within an UpdatePanel, when you browse the page using recent versions of Chrome, Firefox or Safari (and probably other browsers) these fields do not postback.

The impact of this is that using the Toolkit prevents the HTML5 fixes in the Reliability Update 1 from working and HTML5 input controls do not work with browsers other an IE.

The sample code attached can be used to demonstrate the problem. In a brand new, empty web site project the code works with Chrome etc. but in a site that references the Toolkit, it does not.

file attachments

Closed Sep 24, 2012 at 9:08 AM by Superexpert
Fixed in September 2012 release.

comments

giblet wrote Feb 28, 2012 at 12:10 PM

There is no way to resolve this without an update to the toolkit, as I cannot get a debug version of the Toolkit version of MicrosoftAjaxWebForms.js. I've had to remove the toolkit in order to get different input types to work (this is more important than other toolkit functionality for me).

giblet wrote Feb 28, 2012 at 12:56 PM

Here;s a temp fix, copying over the new input checking

pOcHa wrote Mar 7, 2012 at 11:34 PM

@giblet: where is the fix?

giblet wrote Mar 23, 2012 at 10:34 AM

It's the 3.js attached above

pOcHa wrote Mar 23, 2012 at 12:08 PM

Thank you giblet, but I figured it out on my own too.

For everyone else - download the source code, replace the file "PageRequestManager.js" with the file "3.js" attached above (rename it first), rebuild the project and get the new "AjaxControlToolkit.dll"

The fix is only 2 lines long, so I am attaching the the new dll file for .Net 4.0 as a convenience to others.

MarjaR wrote May 10, 2012 at 8:41 AM

This seems like a very simple thing to fix in the toolkit. Why is this still not fixed in the May 2012 release?

pOcHa wrote May 23, 2012 at 9:52 PM

"3.js" is actually "MicrosoftAjaxWebForms.js" (what you get when "PageRequestManager.js" gets combined with a couple of other javascript files at build time), wasn't my upload so presumed it was the right file - dont use "3.js", use newly attached (May 2012 release) "PageRequestManager.js" instead.

pOcHa wrote May 23, 2012 at 10:02 PM

And here are the fixed binaries of the May 2012 release - or you can just download the source, replace "PageRequestManager.js" with the attached one (just 2 lines of difference), and build it yourselves.

Why is this assigned a "low" impact, when it is a completely feature breaking bug, and why it wasn't fixed in a whole 6 month period between releases !?

This is the last time I'm doing this, from now on I'm using Juice UI instead.

ehsanelahimalik wrote Aug 2, 2012 at 9:20 PM

This problem exists from more than a year and is a known problem. I don't understand why it is not being addressed?
Why is the impact set as LOW??? It makes AjaxToolkit incompatible with HTML5 and also it is bricking the fixes done in Reliability Update from Microsoft. I think it should have been addressed on higher priority and should have been included in June release.

ehsanelahimalik wrote Aug 2, 2012 at 9:21 PM

This problem exists from more than a year and is a known problem. I don't understand why it is not being addressed?
Why is the impact set as LOW??? It makes AjaxToolkit incompatible with HTML5 and is actually preventing fixes done by MS in Relibility pack; I think it should have been addressed on higher priority and should have been included in June release.

pOcHa wrote Aug 2, 2012 at 9:53 PM

will upload my fixed source fork tomorrow, and request a pull with the main branch - hopefully that will finally get it included in the next release, otherwise I'm done bothering...