276030 - fontcolor() and big(), at least, give error messages

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[Jonathan Baron]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041222
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041225 and 1224

A few string functions - I've tested fontcolor and big - generate
error messages and don't work.  For example,
"Hi".fontcolor("red")
says that this is not a function.  Other string functions work fine.
The last nightly build where things worked was 12/22/2004.  The problem
occurs in the builds of 12/24 and 12/25.


Reproducible: Always

Steps to Reproduce:
1. in location window, type javascript:alert("hi".fontcolor("red"))
2. open JavaScript console
3. read error message

Actual Results:  
Warning: reference to undefined property "hi".fontcolor
Error: "hi".fontcolor is not a function

Expected Results:  
given an alert with
<font color="red">hi</font>

Comment 1

[Erik Fabert]

See:
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/js/src/jsconfig.h&rev=3.33

The HTML helpers were intentionally turned off.

Comment 2

[Brendan Eich [:brendan]]

I'm going to WONTFIX this bug.  Although it's never good in my book to break
compatibility, the lesser evil still seems to be the choice to reduce code size.
 These HTML string helpers are not implemented by other browsers, not
standardized by any de-facto or de-jure standard apart from SpiderMonkey's
including them, based on the Netscape 2 support in the original "Mocha" runtime.

It's easy to implement these in JS, so I'll attach a lightly-tested
compatibility library here, then close this bug.

/be

Comment 3

[Brendan Eich [:brendan]]

Attachment: JS implementation, use freely

Comment 4

[Brendan Eich [:brendan]]

Per discussion and attachment.

/be

Comment 5

[Jonathan Baron]

(In reply to comment #2)
> I'm going to WONTFIX this bug.  Although it's never good in my book to break
> compatibility, the lesser evil still seems to be the choice to reduce code size.
>  These HTML string helpers are not implemented by other browsers, not
> standardized by any de-facto or de-jure standard apart from SpiderMonkey's
> including them, based on the Netscape 2 support in the original "Mocha" runtime.

OK.  But in other browsers they do not cause error messages or
prevent the entire script from working.  Would it be possible to
do something about that?  It might be better to have it do nothing
than give an error, but I guess that is another judgment call.

(Also, FWIW, Flanagan's "Javascript: The Definitive Guide"
3d ed., does not mention any browser limitations.  In one sense, that
is his problem.  But, in another, the word on this will be slow to get
out if the "definitive" guide misleads.)

> It's easy to implement these in JS, so I'll attach a lightly-tested
> compatibility library here, then close this bug.

Great.  Thanks.

Comment 6

[Brendan Eich [:brendan]]

> OK.  But in other browsers they do not cause error messages or
> prevent the entire script from working.

I'm at a loss to account for this -- what do these methods return, then?  Can
you test in IE6 or Safari?

If they're implemented at all, I would expect them to do what my original
Netscape 2 JS implementation did.  If they are not methods, then calling
undefined is an error, and without exception handling will stop the script (so
you may not see a clear error indication in some browsers, but you should not
see execution continue past one of these method calls).

/be

Comment 7

[Jonathan Baron]

(In reply to comment #6)
> I'm at a loss to account for this -- what do these methods return, then?  Can
> you test in IE6 or Safari?

I don't know about Safari. I have only Linux.  I asked a student to look
at IE, and she found that .fontcolor() works (gives colors) on IE 5.2 for
Mac and IE 6 for Windows.  I have used fontcolor() in many of my questionnaires
listed in http://finzi.psych.upenn.edu/~baron/ex/ , and most of my subjects
still use IE (although I've been telling them for months to get Firefox or
Mozilla).  (Early versions of Safari had a bug that made my questionnaires
fail.)  See, for example: http://finzi.psych.upenn.edu/~baron/hs3.htm

Comment 8

[Brendan Eich [:brendan]]

If IE supports these, we need them back.  But not implemented in C code. 
Perhaps we can hook up the .js file attached to web-page JS standard class code,
so that without hurting page load, these JS implementations get loaded when
needed (and not when they're not used).  jst, any thoughts?

/be

Comment 9

[Nicholas Allen]

Windows scripting should duplicate the Mocha html helper behavior all the way
back except for big which wasn't added until version 3 and fontcolor which they
appear to have broken in .net.  They do use uppercase letters for all of the
tags though.

I'm not a fan of expanding the String prototype after a script has already
started being read in.  I think it's unclear whether string literals can already
have been converted to String objects with the original prototype or whether
they must get the new prototype.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

msie 6.0.2800.1106 seems to support at least "foo".bold() -
javascript:alert("foo".bold()) shows <B>foo</B>.

Comment 11

[Brendan Eich [:brendan]]

> I'm not a fan of expanding the String prototype after a script has already
> started being read in.  I think it's unclear whether string literals can
> already have been converted to String objects with the original prototype or
> whether they must get the new prototype.

It's unspecified by ECMA, but that doesn't matter here: I'm proposing an
implementation detail, and SpiderMonkey conserves the prototype, which is an
object of String class whose identity does not change as it is decorated.

So it is a matter of indifference whether the JS+DOM "engine" uses C or JS to
implement these methods.

/be

Comment 12

[Brendan Eich [:brendan]]

> So it is a matter of indifference whether the JS+DOM "engine" uses C or JS to
> implement these methods.

Unless performance matters so much that C is favored -- but then I'd say there
is a bigger problem. ;-)

/be

Comment 13

[Erik Fabert]

Please keep in mind that the attached script makes these functions turn up
during enumeration of any string. I'd bet some scripters consider |for (i in
str)| to be a nice shortcut for |for (i=0; i < str.length; ++i)|.

Have you considered turning the HTML helpers back on until you have found a
better solution? 

Comment 14

[Brendan Eich [:brendan]]

Erik: yes, and yes (Yes, we shouldn't make JS-implemented helpers enumerable --
but the better way to enumerate chars in a string is for (i=0;i<s.length;i++) as
for-in order is not guaranteed by ECMA -- not that character elements are in
ECMA either!  And yes, I've considered turning the helpers back on).  So much
for footprint wins through obsolescence!

Turned back on, keeping open to continue JS implementation experiments.

/be

Comment 15

[Bob Clary [:bc] (inactive)]

-> default qa

Comment 16

[Brendan Eich [:brendan]]

We could try self-hosting again now that we (are about to) have ES5 enumerable attribute controls, etc., with Object.defineProperty etc.

/be

Comment 17

[Tom S [:evilpie]]

(In reply to Brendan Eich [:brendan] from comment #16)
> We could try self-hosting again now that we (are about to) have ES5
> enumerable attribute controls, etc., with Object.defineProperty etc.
> 
> /be

We have self-hosting filled in other places.