Closed Bug 301869 Opened 15 years ago Closed 14 years ago

Javascript objects not initializing in Deer Park 2 (but work in DP1 and earlier)


(Firefox :: General, defect)

Not set





(Reporter: bucky, Unassigned)




(Keywords: regression)


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

When rendered with Deer Park alpha 1 or earlier, the page in question at hides the textarea and replaces it with a
groovy widgets to help author rich text.

Starting with Deer Park alpha 2, the Javascript fails with an error. The suite
of Javascript scripts aren't of my making (they are instances of the "Xinha"
editor:, so ability to diagnose exactly what might be
happening isn't going to be amazing, but I think that additional javascripts
which are to be loaded by document.write("<script src='..'></script>") calls
aren't being loaded--or else aren't loaded by the time window.onload fires.

In any event, Javascript which was once working (well, I cooked up the page to
demonstrate a problem I'm having with a non-public page) is now failing.

Reproducible: Always

Steps to Reproduce:
1. Visit with Firefox 1.0.x or Deer Park
alpha 1 and see it work.
2. Visit with Deer Park alpha 2 and see it
3. 1 and 2 can be repeated on Linux and in XP
Component: JavaScript Console → General
Keywords: regression
QA Contact: javascript.console → general
Version: unspecified → Trunk
I am also seeing the behaviour as described by steps one & two above, & can
reproduce with latest official Xinha demo too
This is a blocker for Xinha.
*** Bug 310182 has been marked as a duplicate of this bug. ***
(reprinting bug 310182 comment 0 here for reference)

The Xinha text editor (which uses Midas / design-mode) works in FFx 1.0.x but
not in FFx 1.5 (Gecko/20050920 Firefox/1.4). To my untrained eye, it looks like
the problem is that the ternary operator in the body frame's source isn't being
evaluated properly, but I may be wayyy offbase.

Either way, somewhat concerning that JS that worked in previous version doesn't
work in the new version.
Wit the url testcase, I get a js error:
Error: CharacterMap is not defined
Source File:
Line: 5380

what also is important to know maybe is that this:
<script type="text/javascript"
gives a 404 not found error for the character-map.js

So maybe it works when you add that file back to the testcase?
I was getting ready for a mea culpa and a thankful mopping of my brow, but alas,
adding a character-map.js file (a dummy, containing 'var foo="";') didn't do any

It is still the case that Deer Park Alpha 1 and earlier executes this javascript
without errors, but Deer Park Alpha 2 and later produce an error.
Yes, but you probably need to add the character-map.js from xinha:
It can very well be that older Mozilla versions wrongfully not gave a js error,
while current versions do (I suspect that is the case in this bug).

Or you could try removing 'CharacterMap', from this code:
  xinha_plugins = xinha_plugins ? xinha_plugins :
since you don't seem to use it.
Aha. But that's just the problem. NONE of the Xinha plugins seem to work
anymore. Plugins are "registered" as part of a window.onload() method (actually
THE window.onload method, by my reading of the code--I am not a primary Xinha

They are loaded EITHER by a line like this:

    document.write("<script type='text/javascript' src='" + plugin_file +

OR by code like this:

  var script = document.createElement("script");
  script.type = "text/javascript";
  script.src = src;

The only error I get in my javascript console is "CharacterMap is not defined".
CharacterMap is the first function defined in
includes/xinha/plugins/CharacterMap/character-map.js, which should have been
loaded by one of the methods above.

This USED to work, but now has STOPPED working. Because of the text of the
error, I am merely presuming that the loading method is the thing which has
stopped working.

Hopefully, something in my description turns a light on for somebody. I really,
really want Xinha to work when the new Firefox comes out, and I really really
want to fix whatever it is that needs to be fixed, wherever it is that this
change needs to occur.
Alan, if you could attach a zipped file from your example, that would be great.
It would allow me to minimise the testcase to see what's going on.
I diddled the paths a little, since the original used absolute paths. Some of
the images referenced by the .css file are missing (wget didn't find them, and
I didn't bother). Several Xinha plug-ins have been deleted to keep it under the
acceptable attachment size. However, the behavior in question (works in Mozilla
suite, etc., but not in Firefox's most recent beta) is demonstrable here.
Attached file testcase
Thanks Alan!
Well, basically I can reduce the issue to this.
Older builds added an extra newline at the beginning in this case. This was
fixed with the fix for bug 111816.

So the code in htmlarea.js needs to be changed to get this working again.
In HTMLArea.cloneObject = function(obj) 

if (obj.constructor.toString().indexOf("function Function(") == 1) {
you should change into this:
if (obj.constructor.toString().indexOf("function Function(") >= 0) {

Then all should work well again.
You should also change this line:
if (obj.constructor.toString().indexOf("function Array(") == 1) {
into this:
if (obj.constructor.toString().indexOf("function Array(") >= 0) {

Probably the author of htmlarea should also be notified about this, I guess.
Depends on: 111816

I'm not sure if "fixed" is correct, since ultimately this wasn't a Firefox
error, but I now understand the problem and solution.
Closed: 14 years ago
Resolution: --- → FIXED
Resolution: FIXED → ---
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.