Closed Bug 91206 Opened 23 years ago Closed 23 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: frb, Assigned: jst)

References

(
URL
)

Details

Reproduce: 
1> Open http://www.nse-india.com
2> Watch yourself get redirected to:
http://www.nse-india.com/home/cookielogin.htm?userid=null

Expected:
Page should render "normally" like in NS4 

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010712.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Observed on NT.  Changing system from linux to all.
OS: Linux → All
Target Milestone: mozilla1.0 → mozilla0.9.4
Assignee: morse → idk
Status: ASSIGNED → NEW
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
The behavior has changed.  Now instead of getting redirected to the cookielogin 
page, you are getting redirected to

   http://www.nse-india.com/combine/FinalColumn.htm?userid=null

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.
moving to oji
Assignee: idk → edburns
Component: Java-Implemented Plugins → OJI
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
Target Milestone: mozilla0.9.4 → mozilla0.9.5
On a recent trunk, unlike IE, the url gets redirected to 
http://www.nse-india.com/home/cookielogin.htm?userid=null and nothing shows up. 
morse, if this isn't a cookie problem, please reassign to oji or network.
Assignee: karnaze → morse
Component: Layout → Cookies
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
This is neither java nor cookie problem.
Shortest testcase demonstrating the problem:

---- test.html ----
<script>
var name = null;
if (name)
    alert("suck!");
else
    alert("all right");
</script>
<html>
</html>
-------------------
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:
<script>
...
 var name=getCookie("username");
if(name!=null) window.location.href="../home/cookielogin.htm?userid="+name+"";
...</script>

-> javascript? :-)


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

                          if(name)
                      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)
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

                         while(status)
   

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.

It's probably also dependant on bug 69468: DOM strings can't be null or compared
to a null string
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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
object.
Is there anything we can do on our side?
Pushing to mozilla0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
The fix for bug 110397 also fixed this problem. Marking FIXED.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.