The Problem with Google Chrome v29

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

https://code.google.com/p/chromium/issues/detail?id=277303

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.

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 dnnsoftware.com/, the JavaScript containing the _doPostBack method is missing.
So dnnsoftware.com 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 ;) http://css-tricks.com/browser-detection-is-bad/

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 http://51degrees.mobi 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!

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.)