In DOM, null values for 'name' evaluate to true (was: web page redirects, java does not start up)

RESOLVED FIXED in mozilla0.9.7



DOM: Core & HTML
17 years ago
16 years ago


(Reporter: Frank Belew, Assigned: jst)



Firefox Tracking Flags

(Not tracked)





17 years ago
1> Open
2> Watch yourself get redirected to:

Page should render "normally" like in NS4 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010712.


17 years ago
Target Milestone: --- → mozilla1.0

Comment 1

17 years ago
Observed on NT.  Changing system from linux to all.
OS: Linux → All


17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.4


17 years ago
Assignee: morse → idk
Component: Cookies → Java-Implemented Plugins
QA Contact: tever → avm
Summary: web page redirects, although cookie is not set → web page redirects, java does not start up

Comment 2

17 years ago
The behavior has changed.  Now instead of getting redirected to the cookielogin 
page, you are getting redirected to

So I no longer see this as being a cookie problem.  Furthermore, the difference 
between this behavior and the behavior on 4.x is that java is supposed to get 
loaded up at this point.  So I suspect that this is a java problem.

Changing summary and reassigning.

Comment 3

17 years ago
moving to oji
Assignee: idk → edburns
Component: Java-Implemented Plugins → OJI

Comment 4

17 years ago
On WINNT with Trunk from 18 July 2001 this does not crash.  The stock ticker 
applet displays, but is clipped improperly.  Looks like a layout problem.  
Changing component.
Assignee: edburns → karnaze
Component: OJI → Layout
QA Contact: avm → petersen


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 5

17 years ago
On a recent trunk, unlike IE, the url gets redirected to and nothing shows up. 
morse, if this isn't a cookie problem, please reassign to oji or network.
Assignee: karnaze → morse
Component: Layout → Cookies

Comment 6

17 years ago
Doesn't sound like a cookie problem to me so I'm reassigning.  If I'm wrong, 
then reassign it back to me.
Assignee: morse → edburns
Component: Cookies → OJI
QA Contact: petersen → pmac

Comment 7

17 years ago
This is neither java nor cookie problem.
Shortest testcase demonstrating the problem:

---- test.html ----
var name = null;
if (name)
    alert("all right");
If you load this page in mozilla, you'll get alert
saying "suck!" ;-)))))))))
In other words, in mozilla JS variable 'name' is always
not null!!!! Changing variable name will fix problem.

As for original url, it contains JS code:
 var name=getCookie("username");
if(name!=null) window.location.href="../home/cookielogin.htm?userid="+name+"";

-> javascript? :-)

Comment 8

17 years ago
Per Denis's comments, re-assigning to JavaScript.
Assignee: edburns → rogerl
Component: OJI → Javascript Engine
QA Contact: pmac → pschwartau
Summary: web page redirects, java does not start up → No such thing as null in javascript (was: web page redirects, java does not start up)

Comment 9

17 years ago
Denis' script produces the desired output "all right" in the standalone
JS shell. The reason it doesn't work in the browser is because 'name'
is a pre-existing property in the DOM.

All global variables in JS are properties of the JS global object.
In the DOM this is the window object, and the this already has a property
called "name" (e.g. It is of type String.

So when the script does 

                          var name = null

the value |null| is coerced to the string 'null' when it is assigned to |name|.
Therefore when you test

                      or  if(name!=null)

the test gives unexpected results, because the value of |name| is the
not the value |null|, but the STRING 'null'.

Reassigning to DOM Level 0 -
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → desale
Summary: No such thing as null in javascript (was: web page redirects, java does not start up) → In DOM, null values for 'name' evaluate to true (was: web page redirects, java does not start up)

Comment 10

17 years ago
NOTE: very similar if not identical to DOM bug 91877

        "Boolean expressions evaluating as strings in the DOM; 
         causes infinite loop upon visiting page"

In bug 91877, the variable name chosen by the Web developers is 'status';
then they test


But the window object already has a property window.status of type String.
So the value of the Web programmer's status variable, whether true or false, 
gets converted to the strings 'true' or 'false', which both evaluate to true.

Comment 11

17 years ago
It's probably also dependant on bug 69468: DOM strings can't be null or compared
to a null string


17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 12

17 years ago
So what do we do about this? Evangelism? Brendan made it clear in another bug
that local variables do not take precendence over DOM properties of the global
Is there anything we can do on our side?

Comment 13

16 years ago
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 14

16 years ago
The fix for bug 110397 also fixed this problem. Marking FIXED.
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.