62485 - (text-ecmascript) script type="text/ecmascript" is not recognized

Status: RESOLVED FIXED

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

Description

[Erik Arvidsson]

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">
         alert("Evaluated");
    </script>


Actual Results:  No alert is done

Expected Results:  Alert expected

Comment 1

[Asa Dotzler [:asa]]

mscott is this you?  is there a person who deals with most of the mime type
relolution and association stuff?

Comment 2

[Hixie (not reading bugmail)]

Braden: here's a bug for you to apply your mime-type-fu. Thanks!

Comment 3

[Braden]

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).

Comment 4

[Hixie (not reading bugmail)]

braden: So this bug should be marked INVALID or WONTFIX?

What does ECMA say we should use as a MIME type?

Comment 5

[Braden]

To your first question: That depends on whether mozilla.org 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 faqs.org came up blank. If none exists,
then I guess they don't.

Comment 6

[timeless]

IMO we should ask IETF for a script/* mime category, however...

from http://www.google.com/search?q=text%2Fecmascript

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. ...
http://www.w3.org/TR/2000/CR-SVG-20000802/script.html

[e-mail] from September 2000: Re: Registration of ...
... vbscript > > http://www.w3.org/TR/SVG/script.html > > text/ecmascript I
brought this up a while ago, see:
http://lists.w3.org/Archives/Public/www-html/1999Sep ...
lists.w3.org/Archives/Public/www-html/2000Sep/0028.html

type Property (IHTMLScriptElement)
... Possible Values text/ecmascript, ECMAScript. text/Jscript, Microsoft®
JScript® (compatible with ECMA 262 language specification). ...
msdn.microsoft.com/workshop/browser/mshtml/reference/IFaces/ScriptElement/type.asp

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.}

Comment 7

[Braden]

"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, mozilla.org/AOL
might. mozilla.org 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.

Comment 8

[timeless]

fwiw, ECMA 290 http://www.ecma.ch/ecma1/stand/ECMA-290.HTM "ECMAScript Components Specification" references text/javascript

Comment 9

[Brendan Eich [:brendan]]

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)
application/ecmascript?

/be

Comment 10

[Brendan Eich [:brendan]]

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.

/be

Comment 11

[Braden]

I think I recall that some versions of IE do not support
"application/x-javascript". Can anyone confirm?

Comment 12

[timeless]

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 
here.

Comment 13

[Dave Hodder]

See also this IETF Internet-Draft:

    http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-00.txt
    http://www.websitedev.de/ietf/draft-hoehrmann-script-types-00.txt

Comment 14

[timeless]

goody. how does one complain about an IETF draft?

Comment 15

[basic]

timeless: I'd assume you want to speak to the author Björn Höhrmann
mailto:[e-mail] 

Comment 16

[Brendan Eich [:brendan]]

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?

/be

Comment 17

[Waldemar Horwat]

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.

Comment 18

[Brendan Eich [:brendan]]

Why is application less desirable than text?

/be

Comment 19

[Braden]

Ping.

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.

Comment 20

[timeless]

Attachment: our open letter

status? the proposal expired (thank goodness?)

Comment 21

[Brendan Eich [:brendan]]

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://news.mozilla.org:119/[e-mail])?  Rayw is Netscape's
most-plugged-in w3c person, IIRC.

/be

Comment 22

[Roger Perttu]

"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
"text/ecmascript".

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.

Comment 23

[Dave Hodder]

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 
shortly."

http://lists.w3.org/Archives/Public/www-svg/2002Nov/0028.html

N.B. If an ECMAScript registration is undertaken by the W3C, it could well 
be 'application/ecmascript' rather than 'text/ecmascript'.

Comment 24

[Jo Hermans]

*** Bug 203548 has been marked as a duplicate of this bug. ***

Comment 25

[Braden]

*** Bug 233334 has been marked as a duplicate of this bug. ***

Comment 26

[Jim Ley]

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 
text/javascript)

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.

Comment 27

[Braden]

So is there any progress toward getting one (or both) of those types registered?

Comment 28

[Jim Ley]

I believe October 2004 will see a new draft.

Comment 29

[Brendan Eich [:brendan]]

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

Comment 30

[jonathan chetwynd]

seems like the tides against us, will there be surfing time left before this
gets resolved?

Comment 31

[Jim Ley]

Brendan, I believe October will see a new draft, there are other people who 
create drafts than the ECMA working group.

Comment 32

[Brendan Eich [:brendan]]

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)?

/be

Comment 33

[Doug Wright]

(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?

Comment 34

[Jonathan Watt [:jwatt]]

*** Bug 271205 has been marked as a duplicate of this bug. ***

Comment 35

[Brendan Eich [:brendan]]

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.

/be

Comment 36

[Brendan Eich [:brendan]]

> 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.

/be

Comment 37

[Hixie (not reading bugmail)]

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.

Comment 38

[Robin Lionheart]

"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.)

Comment 39

[Bjoern Hoehrmann]

A new Internet-Draft is available from

  http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-01.txt
  http://www.websitedev.de/ietf/draft-hoehrmann-script-types-01.txt

If you have comments please send them to the ietf-types mailing list,
see http://www.alvestrand.no/mailman/listinfo/ietf-types for details.

Comment 40

[Rick Beton]

There's a v02 version of the draft available:

http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-02.txt

Rick

Comment 41

[Brendan Eich [:brendan]]

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

/be

Comment 42

[Brendan Eich [:brendan]]

Attachment: proposed change

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.

/be

Comment 43

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 185313 [details] [diff] [review]
proposed change

don't have sr powers so i'll leave that to jst :)

Comment 44

[Johnny Stenback (:jst)]

Comment on attachment 185313 [details] [diff] [review]
proposed change

sr=jst

Comment 45

[Brendan Eich [:brendan]]

Bob, can you compute a frequency breakdown of the four MIME types in the patch,
and any x- variations, using your spidering tools?

/be

Comment 46

[Bob Clary [:bc] (inactive)]

(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.

Comment 47

[Brendan Eich [:brendan]]

Top N for as large a value as N as you can stand?  Thanks, hope the electrical
work went well.

/be

Comment 48

[Bob Clary [:bc] (inactive)]

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.

<http://bclary.com/2004/11/17/>

type.data 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.

Comment 49

[Hixie (not reading bugmail)]

Summary of bc's summary: the only MIME type used on those sites for a language
that we support is "text/javascript".

Comment 50

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-02.txt also
proposes application/javascript.  Should we add that as well?  It's not in
attachment 185313 [details] [diff] [review].

Comment 51

[Brendan Eich [:brendan]]

Attachment: revised to include application/javascript, reordered jsTypes initializer

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.

/be

Comment 52

[Jonathan Watt [:jwatt]]

*** Bug 296989 has been marked as a duplicate of this bug. ***

Comment 53

[Erik Fabert]

*** Bug 297529 has been marked as a duplicate of this bug. ***

Comment 54

[Brendan Eich [:brendan]]

Last call.  I waited a week, so attachment 185481 [details] [diff] [review] is going in today unless
someone objects or suggests an improvement.

/be

Comment 55

[Hixie (not reading bugmail)]

Looks good to me.

Comment 56

[Brendan Eich [:brendan]]

Latest link to i-d:
http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt

Checked in the patch just now, marking FIXED.

/be

Comment 57

[Jonathan Watt [:jwatt]]

What about these locations:

http://lxr.mozilla.org/mozilla/search?string=%22application%2Fx-javascript%22%2C
http://lxr.mozilla.org/mozilla/search?string=%22application%2Fx-javascript%22%29

Comment 58

[Jonathan Watt [:jwatt]]

Attachment: patch other locations

I'm not sure what order is best in some of these files. Maybe someone can make
better suggestion(s).

Comment 59

[Brendan Eich [:brendan]]

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.

/be

>+          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;

Comment 60

[Jonathan Watt [:jwatt]]

Attachment: now addressing brendan's comments

Comment 61

[Brendan Eich [:brendan]]

Comment on attachment 186451 [details] [diff] [review]
now addressing brendan's comments

Thanks again, please check in ASAP.

/be

Comment 62

[Jonathan Watt [:jwatt]]

Comment on attachment 186451 [details] [diff] [review]
now addressing brendan's comments

checked in

Comment 63

[Robin Lionheart]

"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
<http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01349.html>.

Comment 64

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

*** Bug 302105 has been marked as a duplicate of this bug. ***

Comment 65

[Erik Fabert]

*** Bug 303990 has been marked as a duplicate of this bug. ***

Comment 66

[Boris Zbarsky [:bzbarsky]]

The nsContentDLF part of this change caused bug 306502, because it didn't keep
parser in sync.

Comment 67

[Brendan Eich [:brendan]]

I turn in my fake content peer badge and hang my head in shame :-(.

/be

Comment 68

[Jan Kratochvil]

Is currently "application/javascript" (draft standard) expected to work?
Using:
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
http://www.jankratochvil.net/project/captive/
uses:
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).

Comment 69

[Jonathan Watt [:jwatt]]

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.