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.
Observed on NT. Changing system from linux to all.
OS: Linux → All
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
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
Assignee: edburns → rogerl
QA Contact: pmac → pschwartau
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
QA Contact: pschwartau → desale
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
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.