__doPostBack is undefined on DotNetNuke website for IE 10

Question

I have a DotNetNuke site, and today a customer called in and said it wasn't working on IE 10. Specifically the login and register links weren't working, but they do in compatibility mode. I took a look on our test windows 8 machine and saw that it was failing because __doPostBack was undefined. I've been searching for a fix for the last 6ish hours, and what I've been able to find is that apparently the IE10 user agent is covered in the ie.browser file and that I should install this hotfix and reboot the server. That didn't work. I haven't noticed any changes, even though I think the new ie.browser file should match the new user agent.

What other steps can I take to fix the problem? Note: the server is running .NET 3.5 with service pack 1 on Windows server 2003. The site is running DotNetNuke 05.06.02. Any suggestions would be greatly appreciated.

Haihaida

if for any reason you have the directory App_Browsers on your project, and have there the ie.browser, and not change that also but only apply the patch, that updates the global ie.browser, yours project is overight it and not allow the patch to actually fix the issue. The issue here is solve with a change on the browser definitions. – Ennead

@Ennead there wasn't an ie.browser file in my sites App_Browsers folder. – Haihaida

Ok, then for me, download this file http://www.hanselman.com/blog/content/binary/App_BrowsersUpdate.zip and compare if you can the ie.browser with yours on global to see if they are the same. – Ennead

@Ennead I copied that file over and it worked. – Haihaida

Then please edit the answer of remco, type there what you do, and accept that. – Ennead

Answer 1

See this post by Scott Hanselman:

"Bug and Fix: ASP.NET fails to detect IE10 causing _doPostBack is undefined JavaScript error or maintain FF5 scrollbar position"

Variance

I've tried both installing the hotfix and adding the ie.browser file to the App_Browsers folder, rebooting the server after each one. Neither fixed the problem. – Haihaida

Did you apply the hotfixes for all versions of .net? 2.0 and 4.0? I think dotnetnuke 5 and 6 defaults to .Net 2.0 – Variance

I installed the 2.0 hotfix. I don't have .net 4.0 installed on the server. The latest I have is 3.5 sp1 – Haihaida

Weird, maybe dotnetnuke overrides browser detection. – Variance

hanselman.com/blog/content/binary/App_BrowsersUpdate.zip - that has the .browser files that the hotfix is supposed to update. After copying over the ie.browser files, it started working. – Haihaida

It's also worth noting that sometimes you need to force the whole project to recompile before the new .browser file(s) start taking effect. I just edited a file in the App_Code directory, and THEN the .browser file started working. Fixed! – Yusem

The Microsoft Hotfix took very long to install (about 10 Min) but it worked and solved the problem (Server 2003). You saved my (and my girlfriend's) night, thank you! – Dionnedionysia

Answer 2

On my production site I tried a few things and they didn't work.

I installed the hotfix and rebooted - no good

I copied over the updated ie.browser file - no good

I tried modifying the default.browser, the ie.browser, and the mozilla.browser files to enable javascript for everything - no good.

One thing I did that finally made it work (and this should work for EVERYTHING) is in the InitializePage function of the Default.aspx.vb file, I added this line to the start of the subroutine

Page.ClientTarget = "uplevel"

That should (from what I understand) treat ALL browsers as if they can handle javascript and cookies and all that other stuff we need. I feel like that's a pretty safe bet.

Haihaida

Thanks! This did the trick for me. I have a BasePage class that inherits from System.Web.UI.Page, which in turn is the super class for the page classes in a site. I added the preload event handler to BasePage, and the ie10 problem went away. Like this (c#): protected void Page_PreLoad(object sender, EventArgs e) { this.ClientTarget = "uplevel"; } – Landlady

Answer 3

There's another config that if exist in web.config overrides Scott Hanselman's proposed fixes:

<browserCaps>

ASP.NET browser capability sniffer could be configured in 3 ways (overrides each other):

1. Machine wide in <windir>\Microsoft.NET\Framework\<ver>\CONFIG\Browsers
2. Site only by using .browser files in App_Browsers folder
3. Site only by using <browserCaps> Element in web.config

for IE10 add the following case under <browserCaps> <case "Mozilla .. MSIE ..> :

<case match="\d{2,}" with="${version}">
  frames=true
  tables=true
  cookies=true
  backgroundsounds=true
  vbscript=true
  javascript=true
  javaapplets=true
  activexcontrols=true
  tagwriter=System.Web.UI.HtmlTextWriter
  ecmascriptversion=3.0
  msdomversion=${major}${minor}
  w3cdomversion=1.0
  css1=true
  css2=true
  xml=true

  <filter with="${letters}" match="^b">
    beta=true
  </filter>
  <filter with="${extra}" match="Crawler">
    crawler=true
  </filter>
</case>

Rickrack

Anton , Holy crap, you have no idea how long it took me to see that on my project they were defining these in the web config... Thank you so much! – Quan

Been there also :) Glad i could help. – Rickrack