Closed Bug 62485 (text-ecmascript) Opened 21 years ago Closed 17 years ago

script type="text/ecmascript" is not recognized


(Core :: DOM: Core & HTML, defect, P3)






(Reporter: erik, Assigned: brendan)


(Blocks 1 open bug)



(4 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Reported with IE55
BuildID:    20001205
User-Agent from about page: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 
m18) Gecko/20001205

I really don't know what the standardized way to set up the script language is? 
I know it is supposed to be done in the type attribute and not the languange.

Mozilla do support ECMAScript but when using the mime type "text/ecmascript" 
Mozilla does not evaluate the script.

It is probably an easy fix. Just add another entry to supported mime types for 
the script tag.

Reproducible: Always
Steps to Reproduce:
1.Create a script tag that looks something like this:
    <script type="text/ecmascript">

Actual Results:  No alert is done

Expected Results:  Alert expected
mscott is this you?  is there a person who deals with most of the mime type
relolution and association stuff?
Assignee: asa → mscott
Component: Browser-General → XP Apps
Braden: here's a bug for you to apply your mime-type-fu. Thanks!
To what end, I'm not sure... But I guess it's been noted that no such type
currently exists. As far as changing that...

This is a type that would be in the IETF namespace. Getting such a type
registered needs the attention of someone willing to write an RFC *and* at least
somewhat familiar with the ECMA process and movement on this issue (if any).
braden: So this bug should be marked INVALID or WONTFIX?

What does ECMA say we should use as a MIME type?
To your first question: That depends on whether can locate someone
with the qualifications I described.

To the second: I'm not aware of any Internet Draft or RFC on the issue, and a
search for the term "text/ecmascript" on came up blank. If none exists,
then I guess they don't.
OS: Windows 2000 → All
Hardware: PC → All
IMO we should ask IETF for a script/* mime category, however...


Scripting - W3C SVG 1.0 Specification - Candidate ...
... the value strings in event attributes. The value %ContentType; specifies a
media type, per [RFC2045]. The default value is "text/ecmascript". Animatable:
no. ... from September 2000: Re: Registration of ...
... vbscript > > > > text/ecmascript I
brought this up a while ago, see: ...

type Property (IHTMLScriptElement)
... Possible Values text/ecmascript, ECMAScript. text/Jscript, Microsoft®
JScript® (compatible with ECMA 262 language specification). ...

If W3 is polluting text/* maybe we should ask IETF to complain and/or sanction them?

{text used here is within fairuse. to lookup copyright info follow urls given.}
"script" seems like a nice idea, but making it happen would be a lot of work.
Since "application" is reasonable ("text" is not), I'm not sure it's worth it.

The W3C is behaving irresponsibly on this issue. The IETF obviously does not
have any clout with them on its own. As a major implementor,
might. can tell the W3C that it won't take patches to support types
that haven't been registered, but we probably need someone within Netscape/AOL
who's sympathetic to this issue and has ties to the W3C to press the point.
fwiw, ECMA 290 "ECMAScript Components Specification" references text/javascript

QA Contact: doronr → shrir
The best type to use, IMNSHO, is application/x-javascript.  That's the one I
promulgated in 1995, and from all I understand it's a valid x-type still.

Now "JavaScript" may be unpalatable to some who prefer ECMAScript, which sounds
(and was chosen to sound) unpleasantly like a skin disease.  And JS is not all
that "experimental" these days, although there is new stuff in JS1.5, and there
is JS2 coming (versioning is of course handled with a MIME type parameter-suffix
of the form application/x-javascript;version=1.5).

Question for the bug reporter: what version of the ECMA-262 standard (Edition, I
mean) do you intend to use by default (without a ;version= MIME type param) when
you specify text/ecmascript, or (let's agree that text/ is just wrong)

I didn't have anything to do with ECMA-290, but I strongly suspect they just
cribbed the text/javascript that timeless found there from the w3c's html 4.0 spec.

I think I recall that some versions of IE do not support
"application/x-javascript". Can anyone confirm?
Yes I ran across that but i didn't bookmark it. IE only supported three script 
forms, text/javascript, text/ecmascript and I don't remember the third.

Do we have a bug for mozilla not being forward thinking? if at some future 
point the standard becomes application/javascript or script/javascript we need 
for current browser binaries to be able to accomodate this (probably some rdf 
registration source).  It has always bothered me that you can't register new 
types w/ current browsers 'internal' module.

If/When I find that url [re: ie and bad mime support] again, I'll mention it 
goody. how does one complain about an IETF draft?
Summary: script type="text/ecmascript" is not recognised → script type="text/ecmascript" is not recognized
timeless: I'd assume you want to speak to the author Björn Höhrmann 
Waldemar, is the ECMA TC39 working group able to help solve some of the
problems, reported here, with identifying and versioning ECMAScript as a web
content (aka internet media or MIME) type?

We talked about this briefly in the October 30 ECMA TC39TG1 working group
meeting.  The consensus was that one of us -- doesn't matter who -- should
register text/ecmascript (or, less desirably, application/ecmascript).  We'll
also need a way to distinguish ECMAScript Edition 4 from prior versions of
ECMAScript using the mime type via either the version parameter or by also
grabbing text/ecmascript4.
Why is application less desirable than text?


This one's reared its head on the newsgroups again, and we're still missing any
kind of resolution here.

Does anyone know if there will be an update to the Hoehrmann draft, and to what
degree such an update might reflect the comments here?

waldemar: What is the rationale for preferring "text"? RFC 2046 quite clearly
indicates that "application" is appropriate for scripting languages.
Attached file our open letter
status? the proposal expired (thank goodness?)
Timeless, I'll sign that letter.

Dave Raggett of or near w3c (I hope I spelled his name correctly) may be the
person to approach about the text/ bogo-types in HTML4.

Ray, can you help with this (after you have the pleasure of reading this bug,
bug 27912 [resolved wontfix], and the thread starting at
news://  Rayw is Netscape's
most-plugged-in w3c person, IIRC.

"XMTML W3C Recommendation 26 January 2000, revised 1 August 2002" Just mentions
"text/javascript" in section 4.8. Script and Style elements

Microsoft MSDN lists the types in the following order:
text/ecmascript ECMAScript. 
text/Jscript Microsoft® JScript®. 
text/javascript JScript. 

It's unlikely that MS will change and it's likely that someone will use

It would be nice if the Mozilla community could come to some conclusion. IMHO
supporting "text/ecmascript" if only for backward compatibility would be nice.
A recent post regarding media types on the W3C's www-svg list commented that 
the "issue of registration of a MIME type for ECMAscript has also recently 
restarted, and that we do indeed plan to release a registration document 

N.B. If an ECMAScript registration is undertaken by the W3C, it could well 
be 'application/ecmascript' rather than 'text/ecmascript'.
*** Bug 203548 has been marked as a duplicate of this bug. ***
Blocks: 233334
No longer blocks: 233334
*** Bug 233334 has been marked as a duplicate of this bug. ***
With the SVG Mozilla support now being extremely good, and of a similar 
standard to the other major SVG scriptable user agents - ASV and Batik, this 
issue has raised in importance for SVG authors.   The SVG WG stated 
that "text/ecmascript" was the mime-type - ignoring the wiseness of this, all 
the authors and implementors have followed suit and are using this mime-type 
for their content.  Batik notably doesn't support text/javascript (for much the 
same reasons as you don't support text/ecmascript in HTML but do 

To this end, I would like everyone to reconsider the inclusion of 
text/ecmascript - alternatively I believe it's possible to just patch the 
svg:script element so it supports text/ecmascript leaving the html:script 
element alone.

This is now the single biggest problem preventing access to a large amount of 
svg content available today.
So is there any progress toward getting one (or both) of those types registered?
I believe October 2004 will see a new draft.
No, October 28th will see a new face-to-face meeting of the ECMA technical
group.  I'll make sure this gets some attention there.

Assignee: mscott → brendan
Target Milestone: --- → Future
seems like the tides against us, will there be surfing time left before this
gets resolved?
Brendan, I believe October will see a new draft, there are other people who 
create drafts than the ECMA working group.
Jim: sorry, I thought you meant a draft of something from ECMA -- the ECMA TG1
group could help here, even if another SVG draft does something to mitigate things.

What did you expect from the new SVG draft (if that's what you meant by draft)?

(In reply to comment #29)
> No, October 28th will see a new face-to-face meeting of the ECMA technical
> group.  I'll make sure this gets some attention there.
> /be

Any news?
*** Bug 271205 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Macromedia's standards guy, Bill Schulze, has offered to help work with w3c
folks to get the right type(s) registered with the IANA.  I've made an
introduction via email of Bill to Chris Lilley (hope they haven't met yet!  I
presumed not), so we will see what happens next, and I'll update this bug and
bug 267953 when I know more.

> Macromedia's standards guy, Bill Schulze, has offered to help work with w3c

Forgot to note the connection: Bill is ECMA TG1 "convenor", and he and I will
make sure that ECMA TG1 (the technical group that works on the ECMAScript
standards) buy into whatever type(s) get registered.  ECMA will probably be the
registering party, at least for the canonical type.

Please let's just use text/javascript and not make up a third MIME type, by the
way... text/javascript is _very_ widely used, it's a de-facto standard, it works
fine, it's interoperable, it's understood, etc.
Depends on: 267953
"text/ecmascript" is a misbegotten media type based on misinformation in the SVG
standard. Yes, the standards are wrong, and a valid media type,
"application/x-javascript", is widely supported.

But isn't it a shame we evangelize compliance to standards promoting invalid
media types that we don't accept?

Since the W3C has improperly canonized both "text/javascript" and
"text/ecmascript", perhaps we should be liberal in accepting both.

(As for me, I'll continue to use "application/x-javascript" until the IETF most
belatedly approves "application/ecmascript" or whatever.)
A new Internet-Draft is available from

If you have comments please send them to the ietf-types mailing list,
see for details.
There's a v02 version of the draft available:

Moving to the right product so I can mark it blocking.

Component: XP Apps → DOM
Product: Mozilla Application Suite → Core
Target Milestone: Future → mozilla1.8beta3
Attached patch proposed changeSplinter Review
The table's order is not obviously right, and if text/ecmascript really is used
often in SVG'ish content, it should come before application/ecmascript.

Must we support the x- variants of these new types?  If so, the table's
initializer can be extended.

Soliciting review, this patch *might* be good enough for 1.8b3.

Attachment #185313 - Flags: superreview?(bugmail)
Attachment #185313 - Flags: review?(jst)
Comment on attachment 185313 [details] [diff] [review]
proposed change

don't have sr powers so i'll leave that to jst :)
Attachment #185313 - Flags: superreview?(jst)
Attachment #185313 - Flags: superreview?(bugmail)
Attachment #185313 - Flags: review?(jst)
Attachment #185313 - Flags: review+
Comment on attachment 185313 [details] [diff] [review]
proposed change

Attachment #185313 - Flags: superreview?(jst) → superreview+
Bob, can you compute a frequency breakdown of the four MIME types in the patch,
and any x- variations, using your spidering tools?

QA Contact: shrir → bob
(In reply to comment #45)
sure. What kind of page set are we looking at? I can do my "top 69" with 1 level
which will probably get a few thousand pages and take a day or two.
Unfortunately, my electric coop is swapping out a transformer tonight and I will
be without power for a few hours. I can start tomorrow.
Top N for as large a value as N as you can stand?  Thanks, hope the electrical
work went well.

packrat that I am, I forgot I had this data already. This is for my top site
list and the pages linked from their homepages. It is, of course, only a
snapshot of a very limited portion of the full web.

<> has a summary of script|language|type usage.

raw data in the top70.log.gzip (1.5M gzipped). Don't open in firefox unless you
want to "hang" a couple of minutes while it opens. Just save link and gunzip -S
.gzip locally.
Summary of bc's summary: the only MIME type used on those sites for a language
that we support is "text/javascript". also
proposes application/javascript.  Should we add that as well?  It's not in
attachment 185313 [details] [diff] [review].
I'd appreciate comments requiring changes to this patch, this week.  This patch
or something close to it must go in for 1.8b3/Firefox1.1a.

Attachment #185481 - Flags: superreview+
Attachment #185481 - Flags: review+
Attachment #185481 - Flags: approval1.8b3+
*** Bug 296989 has been marked as a duplicate of this bug. ***
*** Bug 297529 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b3?
Last call.  I waited a week, so attachment 185481 [details] [diff] [review] is going in today unless
someone objects or suggests an improvement.

Flags: blocking1.8b3? → blocking1.8b3+
Looks good to me.
Latest link to i-d:

Checked in the patch just now, marking FIXED.

Closed: 17 years ago
Resolution: --- → FIXED
Attached patch patch other locations (obsolete) — Splinter Review
I'm not sure what order is best in some of these files. Maybe someone can make
better suggestion(s).
Comment on attachment 186363 [details] [diff] [review]
patch other locations

>@@ -1187,18 +1187,36 @@ XULContentSinkImpl::OpenScript(const PRU
>           src.Assign(aAttributes[1]);
>       }
>       else if (key.EqualsLiteral("type")) {
>           nsAutoString  type(aAttributes[1]);
>           nsAutoString  mimeType;
>           nsAutoString  params;
>           nsParserUtils::SplitMimeType(type, mimeType, params);
>-          isJavaScript = mimeType.LowerCaseEqualsLiteral("application/x-javascript") ||
>-                         mimeType.LowerCaseEqualsLiteral("text/javascript");
>+          // Table ordered from most to least likely JS MIME types.
>+          // See bug 62485, feel free to add <script type="..."> survey data to it,
>+          // or to a new bug once 62485 is closed.

For .xul files that we host, the likeliest type is not text/javascript -- it's
application/x-javascript.  Put that first with an XXX comment, and I'll approve
this patch.


>+          static const char *jsTypes[] = {
>+            "text/javascript",
>+            "text/ecmascript",
>+            "application/javascript",
>+            "application/ecmascript",
>+            "application/x-javascript",
>+            nsnull
>+          };
>+          isJavaScript = PR_FALSE;
>+          for (PRInt32 i = 0; jsTypes[i]; i++) {
>+            if (mimeType.LowerCaseEqualsASCII(jsTypes[i])) {
>+              isJavaScript = PR_TRUE;
>+              break;
>+            }
>+          }
>           if (isJavaScript) {
>               JSVersion jsVersion = JSVERSION_DEFAULT;
>               if (params.Find("version=", PR_TRUE) == 0) {
>                   if (params.Length() != 11 || params[8] != '1' || params[9] != '.')
>                       jsVersion = JSVERSION_UNKNOWN;
>                   else switch (params[10]) {
>                       case '0': jsVersion = JSVERSION_1_0; break;
>                       case '1': jsVersion = JSVERSION_1_1; break;
Attachment #186363 - Attachment is obsolete: true
Attachment #186451 - Flags: review?(brendan)
Comment on attachment 186451 [details] [diff] [review]
now addressing brendan's comments

Thanks again, please check in ASAP.

Attachment #186451 - Flags: review?(brendan)
Attachment #186451 - Flags: review+
Attachment #186451 - Flags: approval1.8b3+
Comment on attachment 186451 [details] [diff] [review]
now addressing brendan's comments

checked in
"Scripting Media Types" has been approved as an informational RFC, registering
application/javascript, application/ecmascript, text/javascript (marked
obsolete), and text/ecmascript (marked obsolete), according to IETF-Announce
Alias: text-ecmascript
*** Bug 302105 has been marked as a duplicate of this bug. ***
*** Bug 303990 has been marked as a duplicate of this bug. ***
The nsContentDLF part of this change caused bug 306502, because it didn't keep
parser in sync.
Depends on: 306502
I turn in my fake content peer badge and hang my head in shame :-(.

Is currently "application/javascript" (draft standard) expected to work?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Galeon/1.3.21
and it is still not recognized. Page
Content-Script-Type: application/javascript
[^=header, v=body]
<script type="application/javascript" src="../../My/css_inherit.js"></script>

And the .js file is not loaded (it was functional using "text/javascript" before).
This patch wasn't backported to the Mozilla 1.7 branch. You need a build from
the 1.8 branch or from trunk to get this. I tested in FF1.5 b2 and it works fine.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.