If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

SCRIPT LANGUAGE= trumps TYPE= on same tag

VERIFIED DUPLICATE of bug 135493

Status

()

Core
JavaScript Engine
--
major
VERIFIED DUPLICATE of bug 135493
16 years ago
6 years ago

People

(Reporter: mcsmurf, Assigned: brendan)

Tracking

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js1.2], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
User Agent:Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020503
I wanted to visit http://www.spacewalker.com/english/default.asp.
There i had been redirected to
http://www.spacewalker.com/english/default.htm?0.4025938627955692 (the numbers
change every time because of the random function. On this site i have been
redirected to default.asp and then again to default.htm and so on. So I take a
look at the source of default.asp and there it is:
<script language=JavaScript1.2 type=text/javascript>
<!--
var a=0;
if(a=0){
window.document.location.href="http://www.spacewalker.com/english/default.htm?"+Math.random();
a=1;
}
ok a=0 isn't right, I think the writer of this site wanted to write a==0. But
back to this: a=0 should then give back 0 as the result, so you could also write:
<!--
var a=0;
if(0){
window.document.location.href="http://www.spacewalker.com/english/default.htm?"+Math.random();
a=1;
}
But when there stands if(0), this means 0 == false, so Mozilla shouldn't execute
the code within the brackets
(window.document.location.href="http://www.spacewalker.com/english/default.htm?"+Math.random();a=1;)
If I look at this site with MS IE 6.0 all goes right (the asp-site doesn't
change the js-code, it doesn't matter what useragent you use)
(Reporter)

Comment 1

16 years ago
ah sorry, I know whats wrong:
In JavaScript 1.2 "=" is handled like "==" in if-conditions. But Mozilla did it
right because of language=JavaScript1.2. The difference between "=" and "==" is
in JavaScript 1.3 aka ECMAScript. But there is also the type-attribute and this
stands for JS 1.3, so could also say that the type-attribute overwrites the
language-attribute and the interpretation of Mozilla should be JS 1.3 in this case.
Confirming, but I believe we give higher priority to the Language attribute on
purpose...
OS: Windows 2000 → All
Hardware: PC → All
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
should change summary to something like "language attribute does not have
priority" ?
(Assignee)

Comment 4

16 years ago
ECMA does not specify that an unparenthesized = expression at the outermost
level of an if condition should be rewritten as an == expression, that's a
SpiderMonkey JS engine feature from long ago.  It applies now only to non-ECMA
versions such as JS1.2.

I believe the language attribute does have precedence over type, so I'm not sure
why things are busted here.  I have a patch, not yet checked in, for an HTML 4.x
compliance bug complaining about this precedence problem.  The patch makes type
trump language.  But it's not checked in yet, and I've forgotten the bug number
(was it on harishd's list?).  Anyway, here's the patch.

/be
Assignee: rogerl → brendan
Keywords: mozilla1.0
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 5

16 years ago
Created attachment 82334 [details] [diff] [review]
proposed fix

Please help find the dup bug, and dup whichever way makes sense (if the older
bug has no patch yet, dup it forward against this bug).  Looking for r= and sr=
so we can get this into the trunk, and consider for 1.0.

/be
(Assignee)

Updated

16 years ago
Summary: Mozilla executes JS code while condition with if is not met → SCRIPT LANGUAGE= trumps TYPE= on same tag
The older bug has this same patch, looks like.

*** This bug has been marked as a duplicate of 135493 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 7

16 years ago
Verified Duplicate - 
Status: RESOLVED → VERIFIED

Updated

13 years ago
Whiteboard: [js1.2]
You need to log in before you can comment on or make changes to this bug.