Last Comment Bug 776376 - Old FCKeditor versions (e.g. 2.6.6) stopped working due to navigator.productSub sniffing
: Old FCKeditor versions (e.g. 2.6.6) stopped working due to navigator.productS...
Status: RESOLVED FIXED
: dev-doc-needed, regression
Product: Core
Classification: Components
Component: DOM (show other bugs)
: 16 Branch
: x86 All
: -- normal with 1 vote (vote)
: mozilla17
Assigned To: Dão Gottwald [:dao]
:
Mentors:
http://drupal.fckeditor.net/demo
Depends on:
Blocks: 588909
  Show dependency treegraph
 
Reported: 2012-07-22 10:33 PDT by Alice0775 White
Modified: 2014-01-10 10:40 PST (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
unaffected
+
verified


Attachments
patch (4.04 KB, patch)
2012-07-22 11:41 PDT, Dão Gottwald [:dao]
bzbarsky: review+
jst: superreview+
Details | Diff | Review
aurora patch (interface changes removed) (1.76 KB, patch)
2012-07-30 16:03 PDT, Dão Gottwald [:dao]
no flags Details | Diff | Review

Description Alice0775 White 2012-07-22 10:33:40 PDT
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.
Comment 1 Dão Gottwald [:dao] 2012-07-22 11:41:52 PDT
Created attachment 644774 [details] [diff] [review]
patch

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.
Comment 2 j.j. 2012-07-22 11:57:02 PDT
> 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
Comment 3 Morpheus3k 2012-07-22 11:59:22 PDT
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)
Comment 4 Dão Gottwald [:dao] 2012-07-22 13:15:30 PDT
(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...
Comment 5 Boris Zbarsky [:bz] 2012-07-22 13:21:00 PDT
This seems reasonable to me, but then again I'm pretty up for all sorts of UA monkey-business.  jst, gerv, thoughts?
Comment 6 Morpheus3k 2012-07-23 01:52:26 PDT
(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.
Comment 7 Dão Gottwald [:dao] 2012-07-23 02:04:37 PDT
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.
Comment 8 j.j. 2012-07-23 03:12:50 PDT
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.
Comment 9 Gervase Markham [:gerv] 2012-07-23 04:01:58 PDT
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
Comment 10 j.j. 2012-07-23 04:36:12 PDT
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 11 Johnny Stenback (:jst, jst@mozilla.com) 2012-07-24 15:03:23 PDT
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.
Comment 12 Dão Gottwald [:dao] 2012-07-24 15:06:21 PDT
(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 13 Boris Zbarsky [:bz] 2012-07-26 12:58:54 PDT
Comment on attachment 644774 [details] [diff] [review]
patch

r=me
Comment 14 Boris Zbarsky [:bz] 2012-07-26 12:59:29 PDT
Though note that the patch for 16 might want to drop the interface change.
Comment 15 Dão Gottwald [:dao] 2012-07-27 03:03:18 PDT
(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.
Comment 17 Philipp Kewisch [:Fallen] 2012-07-27 05:16:20 PDT
Does this restrict the ability for xulrunner to specify its own strings in the UA?
Comment 18 Dão Gottwald [:dao] 2012-07-27 05:18:53 PDT
(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.
Comment 19 Bruno Marsal (Bullja) 2012-07-27 14:07:43 PDT
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.
Comment 20 Ed Morley [:emorley] 2012-07-27 14:10:48 PDT
navigator.productSub is not the same as user agent; this bug is unrelated.
Comment 21 j.j. 2012-07-27 15:00:46 PDT
(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!
Comment 22 Bruno Marsal (Bullja) 2012-07-27 16:31:33 PDT
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.
Comment 23 j.j. 2012-07-28 01:43:38 PDT
(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.
Comment 24 Ryan VanderMeulen [:RyanVM] 2012-07-28 18:38:34 PDT
https://hg.mozilla.org/mozilla-central/rev/8ddfcd0a45a5
Comment 25 Dão Gottwald [:dao] 2012-07-30 16:03:27 PDT
Created attachment 647339 [details] [diff] [review]
aurora patch (interface changes removed)

[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 26 Dão Gottwald [:dao] 2012-07-31 08:24:44 PDT
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)
Comment 27 Manuela Muntean [Away] 2012-10-26 06:24:42 PDT
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
Comment 28 waren 2012-11-21 01:59:00 PST
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
Comment 29 Dão Gottwald [:dao] 2012-11-21 06:35:36 PST
(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.
Comment 30 Erik Petersen 2012-11-21 06:45:05 PST
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.
Comment 31 Erik Petersen 2012-11-21 06:49:35 PST
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.)
Comment 32 Erik Petersen 2012-11-21 08:35:48 PST
bug reported: bug 814019 https://bugzilla.mozilla.org/show_bug.cgi?id=814019
Comment 33 Tracy Walker [:tracy] 2014-01-10 10:40:24 PST
mass remove verifyme requests greater than 4 months old

Note You need to log in before you can comment on or make changes to this bug.