Build Identifier: http://hg.mozilla.org/releases/mozilla-aurora/rev/c5081fdf23e0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/16.0 Firefox/16.0 ID:20120720042008 http://hg.mozilla.org/mozilla-central/rev/462106f027af Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120722030555 The FCKeditor is not working anymore on Aurora 16.0a2 and later. See http://forums.mozillazine.org/viewtopic.php?p=12153923#p12153923 The site Javascript determine the Browser by using navigator.productSub. See funvtion FCKeditor_IsCompatibleBrowser in http://drupal.fckeditor.net/fckeditor/fckeditor.js Steps to Reproduce: 1. Open Firefox 2. Open http://drupal.fckeditor.net/demo Actual Results: Not working Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/cfaf90b22fc3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120429 Firefox/15.0a1 ID:20120429173440 Bad: http://hg.mozilla.org/mozilla-central/rev/0a796d07499a Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120430075940 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cfaf90b22fc3&tochange=0a796d07499a Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/043266d76bb3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120430 Firefox/15.0a1 ID:20120430034041 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/5b46705ba525 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120430072040 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=043266d76bb3&tochange=5b46705ba525 Regressed by: Bug 588909 NOTE: UA spoofing does not help. Because, UA string(general.useragent.override) does not affect value of navigator.productSub.

Interesting precedent: webkit always returns "Gecko" for product and "20030107" for productSub. So it's probably ok if it doesn't match the UA string.

> http://drupal.fckeditor.net/fckeditor/fckeditor.js This seems is from version 2.6.6, current Version is 3.6.x: http://dev.ckeditor.com/roadmap?show=completed and seems to work: http://ckeditor.com/demo

The problem seems to be this line: > // Gecko (Opera 9 tries to behave like Gecko at this point). > if ( navigator.product == "Gecko" && navigator.productSub >= 20030210 && > !( typeof(opera) == 'object' && opera.postError ) ) > return true ; The solution would be to update CKEditor to the newest version, which works fine: http://ckeditor.com/demo Or to remove this check manually in the js file (if the old version is needed)

(In reply to Morpheus3k from comment #3) > The solution would be to update CKEditor to the newest version From Mozilla's point of view, the viability of this solution depends on how widespread affected versions are. I would usually expect a pretty long tail. Then again, it took relatively long for someone to notice the incompatibility, so maybe those old versions aren't widespread at all...

This seems reasonable to me, but then again I'm pretty up for all sorts of UA monkey-business. jst, gerv, thoughts?

(In reply to Dão Gottwald [:dao] from comment #4) > (In reply to Morpheus3k from comment #3) > > The solution would be to update CKEditor to the newest version > > From Mozilla's point of view, the viability of this solution depends on how > widespread affected versions are. I would usually expect a pretty long tail. > Then again, it took relatively long for someone to notice the > incompatibility, so maybe those old versions aren't widespread at all... You are absolute right. I assumed that this version is not used widely because it was not reported for three Nightly version iterations. Just an idea: Would it be feasible to wait with landing of the patch until the next merge to collect more data? Maybe it is a very uncommon problem.

I don't think we gain anything by not taking this patch. productSub is useless anyway: already meaningless in released Firefox versions, meaningless in webkit browsers, undefined in IE.

People may start thinking it's a nice feature to get Gecko version via "navigator.productStub" (and actually, it is). If landing of this patch delays, "navigator.productSub" should return nothing before we see content which needs Gecko version here.

I don't have a strong opinion here. This is a non-standard DOM property (right?) so we can send whatever we like. Fixing it at the value we used to send before updating the UA to not contain a Gecko version at all seems fine to me. Gerv

Some data: FCKeditor 2.6 released 2008-04-07 last update 2.6.6 released 2010-02-15 ("This is an urgent release mainly targeting a Firefox 3.6 incompatibility" but unrelated here) CKeditor 3.0 released 2009-08-20 ("written from scratch", seems without bug) BTW, they took our lamentable docs seriously: http://dev.ckeditor.com/ticket/2218

Comment on attachment 644774 [details] [diff] [review] patch I don't have a problem with this change either, but as always when changing things related to the UA string, we need to keep an eye out for fallout from this.

(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #11) > Comment on attachment 644774 [details] [diff] [review] > patch > > I don't have a problem with this change either, but as always when changing > things related to the UA string, we need to keep an eye out for fallout from > this. Note that this restores Firefox <16 behavior as far as navigator.productSub is concerned, so it's not actually a change from that perspective.

Comment on attachment 644774 [details] [diff] [review] patch r=me

Though note that the patch for 16 might want to drop the interface change.

(In reply to Boris Zbarsky (:bz) from comment #14) > Though note that the patch for 16 might want to drop the interface change. Yes, I was going to attach a patch with that part dropped.

Does this restrict the ability for xulrunner to specify its own strings in the UA?

(In reply to Philipp Kewisch [:Fallen] from comment #17) > Does this restrict the ability for xulrunner to specify its own strings in > the UA? This patch doesn't affect how nsHttpHandler.cpp builds the User-Agent string at all.

FYI: the webmail of aol.com also seems to identify "Firefox the wrong way" and does show a old version of the interface only. Overrided the useragent string to ... Gecko/20120429 ... and found the new interface appearing. Am I the only one running into services relying on the old useragent string!? (first FCKeditor, now AOL). What about this: Keep the new useragent format, but only on Nightly+Aurora for now. Hopefully every major service provider / developer will find his service / software not working with Aurora versions and will fix it, if they are interested in supporting newer Firefox versions. In a year latest, all unsupported webtools will have been found hopefully and you can do the switch to the new user agent string format.

navigator.productSub is not the same as user agent; this bug is unrelated.

(In reply to Bruno Marsal (Bullja) from comment #19) > FYI: the webmail of aol.com also seems to identify "Firefox the wrong way" > and does show a old version of the interface only. Overrided the useragent > string to ... Gecko/20120429 ... and found the new interface appearing. Please report this to AOL, might be worth a Mozilla bug report too (if there isn't one, I can't find it). It's on you!

Reported the user agent issue to AOL. Waiting for response now. Just read through bug 588909 and found you already did what I thought: keep the new user agent string in Nightly + Aurora and wait until the majority of web pages do the needed changes.

(In reply to Bruno Marsal (Bullja) from comment #22) > Reported the user agent issue to AOL. Waiting for response now. Opend bug 778408 for the AOL issue, please follow up there. It's off-topic here.

[Approval Request Comment] Bug caused by (feature/regressing bug #): bug 588909 User impact if declined: no rich-text editing with old FCKeditor Testing completed (on m-c, etc.): yes Risk to taking this patch (and alternatives if risky): none String or UUID changes made by this patch: none

Comment on attachment 647339 [details] [diff] [review] aurora patch (interface changes removed) this won't be needed anymore with bug 588909 being backed out from aurora (approval pending)

Verified on both MAC & Windows 7 64bit latest beta: -> Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0 , Build ID: 20121023124120 -> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 , Build ID: 20121023124120

is it possible I still see this? we have an old FCKed version, and after today's update to Firefox 17 (Build: 20121119183901), the editor no longer loads. This build is a portable firefox 17, with no addons. I tried a portable firefox 16 (build: 20121005155445) and the editor does work. see also someone else experiencing this with drupal: http://forums.phplist.com/viewtopic.php?f=24&t=38434

(In reply to waren from comment #28) > is it possible I still see this? > we have an old FCKed version, and after today's update to Firefox 17 (Build: > 20121119183901), the editor no longer loads. It's possible that you have server side UA sniffing outside of FCKeditor code. Or maybe you're using some FCKeditor version that parses navigator.userAgent rather than navigator.productSub. I don't have enough data to tell what exactly you're seeing.

Confirming Comment 28: FCKeditor Version 2.6.4.1 does not load (within a web application) when using FF17: nothing to see. IE: no problem. Safari: FCK does not load, but form shows source (html) of editor´s content.

Well, I guess this is a very heavy bug, because the widely distributed FCKEditor can´t be used. (While it´s yet unknown which versions are concerned and how wide they´re distributed.)

bug reported: bug 814019 https://bugzilla.mozilla.org/show_bug.cgi?id=814019

mass remove verifyme requests greater than 4 months old