Closed Bug 374738 Opened 17 years ago Closed 17 years ago

RichTextEditor (HTMLarea) is broken

Categories

(Firefox :: General, defect)

2.0 Branch
All
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

References

()

Details

(Keywords: qawanted, regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

After an update to 2.0.0.3 the rte HTMLarea doesn't work. For example in TYPO3.

Reproducible: Always

Steps to Reproduce:
1.Log In TYPO3 Backend
2.Edit a Text-Element with RTE (if HTMLarea is installed)
Hardware: PC → All
The new bug on the Typo3 bug site is:
http://bugs.typo3.org/view.php?id=5266

Since most users have automated updates this will be a bigger problem very soon.

Something similar happened, when FF 1.5.0.7 was released.

/Chris
I've traced the problem down in the rtehtmlarea extension:

HTMLArea.prototype.stylesLoaded sets a timeout at the end:
  window.setTimeout("HTMLArea.generatePlugins(" + this._editorNumber + ");", 100);

HTMLArea.generatePlugins starts with:
  HTMLArea.generatePlugins = function(editorNumber) {
    var editor = RTEarea[editorNumber]["editor"];


RTEarea[1]["editor"] is null when generatePlugins gets called, even if using 0 as a delay for setTimeout().

Then further down a Javascript error occurs because of this.

RTE is a global variable, and "editor" gets set there like this (in HTMLArea.initEditor):
  RTE["editor"] = new HTMLArea(RTE["id"], config);
  var editor = RTE["editor"];

It seems like the RTEarea[1]["editor"] property gets nulled somehow accidentally, maybe in conjunction with the window.setTimeout() handling.
Version: unspecified → 2.0 Branch
Severity: critical → major
Keywords: qawanted, regression
Summary: Don't show's the RichTextEditor (HTMLarea) → RichTextEditor (HTMLarea) is broken
Carsten found out that this regressed between 2007-022-6 03 and 2007-02-27 04:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-26+02&maxdate=2007-02-27+09&cvsroot=%2Fcvsroot
This is when the version number was bumped for Firefox2.0.0.3.
So when I used my 1.8 branch build of 2007-03-09, the rich editor wasn't working, but when I switched my user agent to:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1
then suddenly it was working again.
So this seems to be a case of bad user agent switching.
Severity: major → critical
(In reply to comment #3)
> So this seems to be a case of bad user agent switching.
 ..of bad user agent detecting, I meant.

i can confirm martijn`s comment #3

I`ve done some tests with the user agent switcher https://addons.mozilla.org/firefox/59/ and the 2007-02-27 04 Build:

The RTE editor don`t work on the 2007-02-27 04 Build, BUT if i change the User agent to the 2002 Release, i can work with the RTE Editor on the 2007-02-27 04 Build and its working fine.
The workaround with user agent switching leed me to the minimal change needed:

The only change one need is to replace the 1.3 in the version string, with e.g. 1.2

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
will be
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070309 Firefox/2.0.0.3

That goes in conjuntion with an line:
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && (HTMLArea.agt.indexOf("1.3") != -1));
in htmlarea.js on line 85

so it seems to be not an firefox bug
As Axel Klarmann stated, this is not a Firefox bug, but related to rtehtmlarea extension of TYPO3. The bug in TYPO3 already has been solved.

http://bugs.typo3.org/view.php?id=5266
i resolve this as invalid, since this is no Firefox Bug (see comment#6 and #7) and is also fixed now in http://bugs.typo3.org/view.php?id=5266
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.