The reason for this problem is the way Firefox tells it's version number. String "17.0 fir" is not able to parse to double and thus any comparing to version number can't be done.

Also, anyone running Microsoft IIS and using the ASP.net embedding of FCKeditor versions 2.5.1 or 2.6.3 or earlier has a remote file execution security vulnerability. You need to upgrade. See: http://www.securityfocus.com/archive/1/513422/30/0/threaded

Gerv

This is going to be a MAJOR problem for a lot of webmasters who run DotNetNuke as a CMS as many versions of DNN have shipped with FCKeditor.

In addition, after upgrading to Firefox 17, I am having an issue where a website navigational menu module is now no longer functioning on one of my customers websites - See www.rmtb.org for an example of the broken menu on my customer's live production website.

Now what to do? Why the update with all the problems? This is going to cause a huge mess for a lot of people. The quick fix for me will be to abandon Firefox altogether and recommend as such to everyone I know and support as well, unfortunately. It was a nice ride while it lasted.

Veriatech - I echo your sentiments. Firefox 17 also broke my fckeditor and menu in my clients websites. Unless Firefox does something about these issues urgently, I feel a lot of web masters will abandon Firefox and quite rightly it was a nice ride while it lasted.

The change which caused this problem is being reverted in Firefox 17.0.1.

However, any site which was broken by this change is also broken in Firefox for Android and Firefox OS, which have had the updated user agent for quite some time. Therefore, you are encouraged to fix them anyway.

Gerv

My questions are, why is this not an issue in any other browser software, such as Internet Explorer and Chrome? And where can I specifically find more information about the "updated user agent" and how to provide a custom fix to my customer's websites? To the Firefox development team: This is NOT best practice. If you release an update that breaks websites, you are going to lose market share, plain and simple. That's the bottom line here. Webmasters are getting phone calls by customers. Phone calls take their time. Time is money. Understand? We obviously won't bill our customers for the time it will take us to "fix" this debacle, which you released. From my chair, Firefox now has a black eye, which is too bad. I had grown very fond of Firefox up until now.

In an unwise but common programming pattern, web developers scan the "User Agent" string which identifies the browser to try and determine its capabilities. In Firefox 17, we made a change to that string to eliminate a part of it which had been static and vestigial for nearly 3 years, and replace it with a more useful version number. Unfortunately, there appears to be more old code than we thought which takes action based on the original value.

This is not the case for IE and Chrome because a) those browsers have different user agents which are detected in different ways, and b) presumably they have not recently made a change. Although the User Agent does change when a new version is released of e.g. IE, or for IE Metro with Touch, or for other similar reasons. This is why User Agent sniffing is a bad idea.

To fix your customer's websites, you can either wait for Firefox 17.0.1 or you can find the code which checks the "gecko date" in the User Agent string and work out what it's doing with that information and how to get it to do the right thing instead of the wrong thing with the new value.

Old (Firefox 16 and 17.0.1): Gecko/20100101

"New" (Firefox 17.0.0): Gecko/17.0

"If you release an update that breaks websites, you are going to lose market share, plain and simple."

The web is big enough and diverse enough that pretty much any change will break _something_. The web is a living and growing thing; that means that both browsers and sites need to be actively maintained to account for changes in the other. Having said that, this breakage was unexpected and larger than anticipated, which is why we are reverting the change.

I too am using fckEditor.Net and was able to fix this problem by adding the following in the "OnPreRender" code of FCKEditor.vb (which inherits from FredCK.FCKeditorV2.FCKeditor)

m_IsCompatible = Me.CheckBrowserCompatibility() If Page.Request.Browser.Type.Contains("Firefox") Then

     m_IsCompatible = True

End If

Hope this helps someone

For the PURE JS versions you also need to: Open fckeditorcode_gecko.js look near line 121 - you will see something about "function(A)" - now you're in the right area.

look at/near line 125 A.IsGecko10 = B < 20051111;

problem: B == 17 (not a date anymore)

change it to something like this: if(B < 100){

           A.IsGecko10 = false;

}else{

           A.IsGecko10 = B < 20051111;

}

By using B < 100 I'm basically differentiating between date or non-date

That code will break in 10 years. Say 1000 instead of 100.

Gerv

And really, for me, this update / breakage wasn't so much about the fckeditor issue (I realize that's what the thread subject was titled) but more about the fact that my customers external facing website presences are perceived broken by site visitors using the updated Firefox 17 browser. Being a techie, a webmaster... I expect there are going to be problems on the backend. It is the front end I am most concerned about. This is the first time in all my years on the web (since 1997) a website went down as a result of a browser update.

I am still having an issue after applying the suggested fixes, matching the version or just returning true.

I get a TypeError either way saying that the FCKeditor API is undefined, resulting in a broken blank area where my input field used to be.

It remains functional in Chrome and other browsers.

Found it ! Firefox 17 is acting like gecko 10

1. Edit file "fckeditorcode_gecko.js"
2. Search for a line "A.IsGecko10=B<20051111"
3. Replace it by "A.IsGecko10=false

Enjoy it !

The latest Firefox update has fixed the problem. Thank you.

Thank you Firefox development team for fixing the problem and publishing the fix via the latest 17.0.1 update! All is once again well (at least where this issue was concerned) in my world!

Yes thanks firefox for sorting it... it seems fine now but please do more testing for future updates... this was a serious situation that could be snowballed. Webmasters worldwide can breath a sigh of relief.

The fix is that they have decide to back out the bug fixes via Bug 815743 that initially caused this issue by modifying the user agent and that changed the Gecko/<date> (Gecko/20100101) part to Gecko/<Firefox version> (Gecko/17.0) (Bug 588909).
There were already a lot of prefs defined in Firefox 17.0 that allowed to override the user agent for specific known websites and that now no longer are required.

This problem is solved with Firefox 17.0.1... This browser is great thanks to things like this: speed and proximity with users. Greetings!