Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

The Problem with Google Chrome v29

Yesterday afternoon some folks using the website with Google Chrome began to experience some strange behavior; they couldn’t log in! Some were enterprising and just switched browsers; nobody had any problems with Firefox, Internet Explorer or Opera. But others started to alert us via email and Twitter. “What’s going on?” they asked. 

It appears that the latest update to Google Chrome (Version 29.0.1547.57 m) doesn’t work / play well with some .Net websites. At first, we started investigating this as a potential DNN issue… but we soon found the problem was not limited to DNN websites. Many of our own favorite sites (running .Net) are experiencing the same or similar issues. Additionally, we've found that the behavior seems to be most attributable to specific servers. That is that sites running on some servers exhibit this behavior and sites configured on other servers don’t. This is not a scientific conclusion, but the anecdotal and experiential evidence being logged by our MVP’s seems to bear this out. But what is different about the servers?

 Today, most of us are now able to log in to using Chrome. A simple Ctrl-F5 might be required… but apart from that we know of nothing that has “changed”. We have not updated our software, our website or our servers; neither has any of us updated our browsers. But it seems to be related to the User Agent that is communicated to the site from the browser ( as demonstrated here: ).

 As we continue to learn more about this issue we’ll keep you updated. But we wanted you to know about it and give you some insight and suggestions. So for now if you’re experiencing this issue, you have a couple of potential workarounds:

1.       Use another browser besides Chrome to work on the website (IE and FF both work well).

2.       Follow the instructions in the screencast above to get yourself logged in.

3.       Uninstall Chrome v29 and install an older version (ie. v28 and turn automatic updates OFF)

We'll let you know as we learn more!



phil wegrzyn
Looks like the problem is now resolved (apparently it was the file didn't resolve chrome v29 version# properly).

I just did an appPool restart of all my sites, and they are now all working again with Chrome . So glad this got fixed before the weekend, thanks to everyone who helped figure out the problem and resolve it.
phil wegrzyn Friday, August 23, 2013 3:38 PM (link)
Roland W
I seem to have a very similar problem with SeaMonkey, although it has nothing to do with recent change to SeaMonkey, my five month old version just stopped working, updating it to the recent version didn't solve the problem.
(FYI: SeaMonkey is the former Mozilla suite, which is the former Netscape Navigator suite and Firefox basically is SeaMonkey without the e-mail client, chat client and such. Or Firefox is the browser part of the SeaMonkey suite, whichever way you like to look at it. Both use the Gecko render engine to surf the web.)

They both do exactly the same HTTP requests, with the only exception that SeaMonkey has it's name and version appended to the user agent string. But in the response SeaMonkey gets form, the JavaScript containing the _doPostBack method is missing.
So is returning code based on the user agent string, and in the process is proving that is a really really bad thing to do, because it impossible to do correctly. (What part of the user agent string triggered them to leave out the JavaScript (JavaScript degrades gracefully) anyway? Omitting the JavaScript method while still including the call to that method is just buggy code, there is no excuse for that.) Judging the browser on it's brand instead of it's capabilities is like racism for browsers ;)

Roland W Wednesday, August 28, 2013 5:10 AM (link)
Scott Willhite
Greetings Roland ~ I think we are in agreement that browser detection is tricky business. But in a world where the a site can be displayed on thousands of different devices, with hundreds of thousands of combinations of attributes, it is essential that some intelligence be applied to the problem. We rely on the experts at to detect browser and device capabilities so that DNN sites can finely taylor user experience to the devices they serve. As we experienced this week, sometimes new things don't fit well into the existing detection schemes... but that's why its important to have a relationship with a company that monitors and responds to these changes quickly. We're pleased that 51degrees generously provides their basic database and service to all DNN sites free of charge (their professional version is included in our Evoq products). Obviously, I cannot explain what might be going on with your situation in particular... but I'll make an inquiry with 51degrees. Cheers!
Scott Willhite Wednesday, August 28, 2013 12:55 PM (link)
Roland W
Hi Scott,

No, we are definitely not in agreement. It's not tricky business, it is a flawed concept altogether. The web has been designed to allow the detection of capabilities and if something isn't supported, to degrade gracefully. The user agent was never (and still isn't) designed for this. Javascript capabilities can be tricky and you do not want to figure everything out yourself, but then use jquery or something, don't use the user agent string.

As a proud user of SeaMonkey (which isn't even a very obscure browser, long ago it has been the most used browser in the world for a long time and it's browsing engine is still being developed as it uses the exact same Gecko engine as Firefox) I'm often confronted with malfunctioning or stripped down sites because they take (wrong) decisions solely based on the user agent. Even google serves me pages as if I were using a browser from the stone age (and also redirect me to the Dutch google site as they decide that I prefer Dutch language based on my IP address, even though my browser settings clearly state I prefer English (which is included in every http-request a browser makes.)

The user agent string doesn't tell you anything about the screen size and whether or not a user isMobile (whatever that might mean), but they do use it for exactly that purpose. All kind of assumptions are made about internet connection speed, screen size, input devices, the availability of Flash, Java, cookies, etc based on the user agent string while the only guarantee you have, is that these assumptions will not always be correct. They could/should have been detected, not assumed.
(An other flawed assumption that is often made, it that everybody uses its browser full screen so the website's width could match the screen size. Even google analytics (by default) reports the screen size but not the browser size.)

I've seen examples were a Windows phone gets the desktop version of the site (because it's 'Windows') while when I place my smartphone in it's dock and it's connected to high speed wifi, a Full-HD screen and a regular keyboard and mouse, I still get the mobile sites because there once was a time android was only used on small phones.

OK, 51degrees fixed the problem with chrome29, but the same bug with SeaMonkey (any version) they introduced at the same time... When will that be fixed? I expect to be told that my prefered browser doesn't have their priority and I'll just have to wait when (if at all) they will fix it. And again, there is nothing wrong with my browser, it's more than capable of accessing the sites, I'm only denied access to DNNsites because of my user agent string.
So should I change my user agent string to impersonate Firefox and at the same time make the developers feel that even less people are using SeaMonkey, so the issue gets even less priority? And while more and more people are forced into changing the user agent string, the browser agent detection becomes even more flawed.
It has become so bad that Mozilla found it necessary to identify SeaMonkey as both SeaMonkey and Firefox in the user agent string. And still a company who made it it's sole business fails in correctly providing the correct capabilities.

Why can I browse some sites with a browser that doesn't support cookies, but can't I browse those same sites using a browser that supports cookies, but has cookies disabled?
Will a new browser (no matter how perfect it is) ever be able to become successful when it's users are turned down because unnecessary browser detection which isn't working properly?

The user agent string should not be used to detect the capabilities of a browser!

You make it so much harder on yourself as instead of having to debug why a certain functionality doesn't work, you now have to debug why some very specific browser (you probably don't have access to) doesn't work. User agent based browser capability detection does not make life easier at all.
Instead of just detecting whether some capability is available at the spot where you want' to use it (which is something HTML does for you by design), you're trying write a site based on the user agent string assumption, which is much harder to do even when 51degrees would de the detection for you perfectly. The problem with Chrome29 illustrated that not only can the detection fail, there also is some flaw in the site which serves Javascript to a browser which is 'detected' not to support Javascript. If graceful degradation were applied, this programming error would have been prevented by design.
We know we shouldn't include IE-specific code/css files in a site, we know we shouldn't make sites depending heavily on Javascript, Flash and or cookies, we know we shouldn't use tables for layout, we know we shouldn't use frame sets, to we know we should use responsive design to enable mobile use of our site (and printing) instead of creating seperate mobile sites (or printer friendly pages) and we know browser capability detection should not be done using the user agent string. It's sad/frustrating to see that a company who made a flawed concept its sole business is desperately trying to tell us otherwise. But hey, they can't tell you what they are doing is wrong and still make money, can they?

I guess that when you're using IE, Firefox, Safari or Chrome (<29) you might hardly ever be confronted with these failures, but when using a less known browser -even those using the same render engines- you know these problems exist. It's sad to see how often switching to an other user agent string fixes errors.

(Sorry for any the spelling errors, English isn't my native language and I had to use Firefox (which doesn't have the spelling checker installed which I do have installed in SeaMonkey) to post this message.)
Roland W Thursday, August 29, 2013 7:42 AM (link)

Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (22)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?