The default bug view has changed. See this FAQ.

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

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
P3
normal
RESOLVED WORKSFORME
12 years ago
3 years ago

People

(Reporter: Jonathan Baron, Unassigned)

Tracking

({js1.5})

Trunk
mozilla1.8alpha6
js1.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

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

The HTML helpers were intentionally turned off.
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
Created attachment 169599 [details]
JS implementation, use freely
Per discussion and attachment.

/be
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

12 years ago
(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.
> 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
(Reporter)

Comment 7

12 years ago
(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
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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 9

12 years ago
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.
OS: Linux → All
Hardware: PC → All
msie 6.0.2800.1106 seems to support at least "foo".bold() -
javascript:alert("foo".bold()) shows <B>foo</B>.
> 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
Status: REOPENED → ASSIGNED
> 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

12 years ago
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? 
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
Keywords: js1.5
Priority: -- → P3
Target Milestone: --- → mozilla1.8alpha6

Comment 15

12 years ago
-> default qa
QA Contact: pschwartau → general
We could try self-hosting again now that we (are about to) have ES5 enumerable attribute controls, etc., with Object.defineProperty etc.

/be
Status: ASSIGNED → NEW
(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.
Status: NEW → RESOLVED
Last Resolved: 12 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.