Last Comment Bug 276030 - fontcolor() and big(), at least, give error messages
: fontcolor() and big(), at least, give error messages
Status: RESOLVED WORKSFORME
: js1.5
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: mozilla1.8alpha6
Assigned To: general
:
: Jason Orendorff [:jorendorff]
Mentors:
http://finzi.psych.upenn.edu/~baron/e...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-26 05:09 PST by Jonathan Baron
Modified: 2014-04-26 03:09 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
JS implementation, use freely (1.29 KB, text/plain)
2004-12-26 10:14 PST, Brendan Eich [:brendan]
no flags Details

Description Jonathan Baron 2004-12-26 05:09:55 PST
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 2004-12-26 06:52:23 PST
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] 2004-12-26 09:59:08 PST
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] 2004-12-26 10:14:07 PST
Created attachment 169599 [details]
JS implementation, use freely
Comment 4 Brendan Eich [:brendan] 2004-12-26 10:14:51 PST
Per discussion and attachment.

/be
Comment 5 Jonathan Baron 2004-12-26 10:19:37 PST
(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] 2004-12-26 14:51:39 PST
> 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 2004-12-26 16:04:15 PST
(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] 2004-12-26 16:09:28 PST
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 2004-12-26 17:18:29 PST
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) 2004-12-26 17:51:09 PST
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] 2004-12-26 18:53:30 PST
> 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] 2004-12-26 18:57:13 PST
> 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 2004-12-28 01:03:35 PST
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] 2004-12-28 08:44:16 PST
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:] 2005-09-04 12:31:00 PDT
-> default qa
Comment 16 Brendan Eich [:brendan] 2009-11-17 07:13:36 PST
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 Schuster [:evilpie] 2011-10-07 03:54:03 PDT
(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.

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