<SCRIPT LANGUAGE="JavaScript1.0"> gets ignored

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
17 years ago
4 years ago

People

(Reporter: Stephen Moehle, Assigned: timeless)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
The above URL has an image HREF that is placed in a form through JavaScript and
document.writeln.  The image does not show up in Mozilla though it is visible
using NN4 and Opera5.  The image says "Register" in white text on a red
background and appears at the bottom of the "Become a member!" section.

The code that writes the image looks like:

<script language="JavaScript1.0" TYPE="text/javascript">
<!--
document.writeln("<A HREF=\"javascript:;\" onClick=\"if
(form_check(document.register_form)) document.register_form.submit(); return
false\" onMouseOver=\"window.status='Register';return true\"
onMouseOut=\"window.status='';return true;\"><img
src=\"https://a248.e.akamai.net/7/248/1692/0077/www.half.com/images/button_register.gif\"
WIDTH=\"74\" HEIGHT=\"18\" BORDER=\"0\" VSPACE=\"6\"></A>");
//-->
</SCRIPT>

To reproduce:
1) Go to the above URL.  The "Register" image is not visible.

Tested with Mozilla trunk build 2001070710 on Linux.

Comment 1

17 years ago
confirmed 2001070604 w2k

The problem is the part LANGUAGE="JavaScript1.0", see attached testcase.
Move to Browser/Javascript Engine

I'm almost sure this bug must be a duplicate =) I'll search...
Status: UNCONFIRMED → NEW
Component: Browser-General → Javascript Engine
Ever confirmed: true
Keywords: testcase
OS: Linux → All
Summary: JavaScript created image link not visible in page → JavaScript 1.0 created image link not visible in page

Comment 2

17 years ago
Created attachment 41595 [details]
testcase

Comment 3

17 years ago
Since it ignores all commands and i cannot find a duplicate I'll change the
subject once again..
Summary: JavaScript 1.0 created image link not visible in page → <SCRIPT LANGUAGE="JavaScript1.0"> gets ignored

Comment 4

17 years ago
There is no JavaScript1.0 is there? I always thought the valid languages were
JavaScript, JavaScript1.1, JavaScript1.2, etc. 
I thought 1.0 was assumed for the plain "JavaScript" language. If that is the
case, then Mozilla is right in ignoring the script... It doesn't recognize that
language and so wont parse it. I do feel however, that JavaScript1.0 is probably
a likely thing to see on web sites and maybe we should accept it. Does anybody
with more JavaScript experience know the semantics of this?

Comment 5

17 years ago
I just got hit by this bug as well.  I searched for "javascript1.0" in
comp.lang.javascript on google groups, and I got 50 odd hits, quite a few from
people who look like they write a lot of javascript.  So I think you should
favor pragmatism over correctness in this case.
(Assignee)

Comment 6

17 years ago
.
Assignee: asa → rogerl
QA Contact: doronr → pschwartau
Bug is in nsParserUtils::IsJavaScriptLanguage, in
content/base/src/nsParserUtils.cpp.  timeless has kindly offered to patch.

/be
Assignee: rogerl → timeless
Component: Javascript Engine → DOM Content Models
(Assignee)

Comment 8

17 years ago
Created attachment 42965 [details] [diff] [review]
recognize 1.0

Comment 9

17 years ago
One comment about the patch... Since "JavaScript1.0" is not considered a
recognized type anyway, (The JS3.x Reference provides the valid types for 1.0-1.2)
And since we're taking it to mean type="JavaScript" anyway, shouldn't we include
it with the first 'if' to assign the value JSVERSION_DEFAULT? 

I'm just thinking aloud... but if I were parsing an HTML file I would assume
"JavaScript1.0" was "JavaScript"
No, an explicit version is different from the default version.  The default
version is free to extend the language in compatible ways (see ECMA Edition 3's
Errors chapter).  An explicit version should select a version of the language
that is free of such extensions.

As you note, 1.0 was rationalized after the fact, so it's not clear what people
mean when they select it -- but I bet they want something older and mustier than
1.1, which was what fed into ECMA.  For instance, they may want assignment to a
readonly property to be an error.  If someone could analyze those pages
disclosed by a web search that select "JavaScript1.0" and say more, that would
be swell.  Otherwise, I'd err on the side of explicit-implies-conservatism.

/be
Timeless was whinging at me on #mozilla about this bug, but I do not see anyone
summarizing what the public pages with <script language="JavaScript1.0"> seem to
want: JSVERSION_1_0 or JSVERSION_DEFAULT.  Anyone?

/be

Comment 12

17 years ago
cc'ing Ian, Jesse
*** Bug 93504 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
The script from bug 93504 appears to use Javascript and Javascript1.0
interchangably. I can't seem to find any reason that the page really wants
*only* javascript1.0

Also, from searching the internet, It seems many Javascript help pages (and
college courses) are telling people to use "JavaScript1.0" where the Netscape
Reference says to use "JavaScript"

Does anyone know what NS4 did? because that is at the moment the behavior we
should emulate. 
*** Bug 95546 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

17 years ago
Oh that last one is easy. NC4 treats this as a noop. ie clicking the above link 
will give you "Can you read this-->" in NC4 and currently in Moz. Whereas some 
people apparently expect "" (and it would seem JS1.0 behavior).

anyone want to r=?
Assignee: timeless → timeless
Keywords: approval, patch, review
*** Bug 96077 has been marked as a duplicate of this bug. ***
timeless: I'm happy to r= or sr=, but wonder what link you mean.  Also, I like
your patch's implication of JSVERSION_1_0 from "JavaScript1.0" because it is the
most conservative approach, but it sure sounds like some pages foolishly expect
"ECMA" or "latest (1.5)" JS when they say "JavaScript1.0", from what Mike Young
reports.  Mike, can we cause those college courses that mislead people into
using "JavaScript1.0" to fix their teaching materials?

/be

Comment 19

17 years ago
We could put this into evangelism, but they're pretty busy. :-)

I dont think they intend to get JS1.5 when they use "JavaScript1.0", but I do
think they expect it will work the same way as if they entered "JavaScript".
here's what I mean...

From what I understand these are the JS versions and how you declare them.

SCRIPT LANGUAGE="

JavaScript -- the first revision NS2.x
JavaScript1.1 -- the second, NS 3.x
JavaScript1.2 -- NS4.0-4.05
JavaScript1.3 -- NS4.06-NS4.78 (
JavaScript1.4 -- (Anything use this?) I guess Moz < M6
JavaScript1.5 -- Mozilla et al

What I see in the "Scripting How-to"s and the few university courses is that
they teach "JavaScript1.0" instead of "JavaScript" for the first revision.
Presumably, the people understand that the code must adhere to JS1.0
limitations. I never meant to insinuate that "JavaScript1.0" should be treated
as JS1.5, but that it should be treated like "JavaScript" (without any version
numbers.)

here is an example from one of the pages I found. (I cant find many of the
others anymore)
------------------------------------------------

One can specify the different versions of the Language

    * e.g.:
    * <SCRIPT LANGUAGE="JavaScript1.1"> Ignored by Netscape Navigator 2.0
    * location.replace("versionofpagefornav3.0.html");
    * </SCRIPT>
    * <SCRIPT LANGUAGE="JavaScript1.0" > Read by Netscape Navigator 2.0
    * ..........

-------------------------------------------------------

In the above case, we wouldn't even get to the 1.0 code, but if we did, I assume
that they mean <SCRIPT LANGUAGE="JavaScript"> since "JavaScript1.0" really
doesn't exist. That's why its confusing as to what is the correct behavior. Most
of the scripts just use them as a way to test for browser versions and we never
really get to them.

If the question is whether we parse LANGUAGE="JavaScript1.0" as NS2.x did or as
we would parse JS1.5 today, I'm inclined to believe that we want NS2.x behavior.
(I really don't think it'll break that many pages anyway.) :-)
r/sr=brendan@mozilla.org on timeless's patch, anyway.

/be
(Assignee)

Comment 21

17 years ago
sorry, i meant the bug url, click "URL:" at the top of the bug.  Anyone want to 
give an r? [and i guess i'll need to hunt for an a?]
Thought maybe N6.1 was ready enough to put on the wife's computer. She nearly
immediately ran into this, and 6.1 now joins the trash heap along with the
earlier versions.

r=dveditz

I'd prefer more context in diffs
Cc'ing some drivers to get their feedback on taking this for 0.9.4.  It's low
risk, and if it helps dveditz's wife use 0.9.4 and/or derivatives, I'm all for it.

/be

Comment 24

17 years ago
I'd also like to see this. a=asa 
(Assignee)

Comment 25

17 years ago
Fix checked in. filed bug 98074 about the wonders of my bug summaries =(, and resolve to reconsider coffee or working while asleep/vacationing.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 26

17 years ago
Verified Fixed using Mozilla trunk binaries 20010909xx WinNT, Linux, Mac.
Status: RESOLVED → VERIFIED

Comment 27

17 years ago
(ALSO VERIFIED WITH 094-BRANCH BINARIES 20010910xx WinNT, Linux, Mac.)

Updated

7 years ago
Component: DOM: Abstract Schemas → DOM: Core & HTML
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.