110230 - var location = window.location reloads current page

Status: RESOLVED DUPLICATE of bug 131212

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

Description

[Robert Ginda]

In 4x (and IE, from what I've heard), the attached testcase shows two alert
boxes and stops.
In mozilla, the test shows two alert boxes, then reloads and shows them again.

Comment 1

[Robert Ginda]

Attachment: html testcase. This will cause an infinite loop in mozilla, don't click on it if you have unsaved data.

WARNING: This testcase will cause an infinite loop in mozilla, don't click on
it if you have unsaved data.

Comment 2

[Karl Johan Kleist]

I can reproduce the problem. Build ID: 2001 11 08 03 / Windows 2000.

Comment 3

[Julien Cegarra]

Confirmed. BuilId: 2001 11 13 03 / Win98

Comment 4

[Fabian Guisset]

that's because var location == window.location, so you're doing window.location
= window.location which triggers a reflow. This is correct per the ecma spec.
The fact that one can trigger an infinite loop is bad though.
We already have a bug about shadowing window.location with a local var location,
but I can't find it at the moment.

Comment 5

[Robert Ginda]

The ecma spec doesn't talk about browser objects, and the w3c spec doesn't talk
about the window object, so I don't know what spec you're referring to.

I realize that var location is an alias to window.location.  This is true even
in 4x, but somehow 4x avoids the infinte loop, and we don't.

Comment 6

[Fabian Guisset]

*** Bug 110310 has been marked as a duplicate of this bug. ***

Comment 7

[Johnny Stenback (:jst)]

The reason this is not a problem in 4x (and IE) is that 4x is not ECMAScript
compliant (nor is IE) and treats:

  var location = "...";

differently than:

  location = "...";

in the global scope. That's a problem that's not fixable in mozilla w/o breaking
ECMAScript compliance.

Comment 8

[Frank Burleigh]

This is difficult.  This breaks the main webified holdings catalog of our campus
library system.  We discovered it when we gave one of the law librarians NS6.2.
 On the one hand, the HTML for the page from which my report (Bug 110310) comes
is very bad, and the javascript seems to run afoul of standards.  On the other,
we need this to work and therefore can't run NS 6.x until it does.  I can make a
go at the technical people in the library but I need to be able to quote the
standard, and I need to be able to explain just where the offending page runs
afoul.  I don't see any use of "location" in the (generated) page that submit
the form that upsets the CGI.

Comment 9

[Johnny Stenback (:jst)]

From Christian Schmidt's comment in bug 110310:

The problem seems to be that a variable with the name "location" is declared.

The behaviour can be reproduced by a page containing the following script:

<script language="text/javascript">
var location;
location = 'abc.html';
</script>

The author of the script appearently wants to override the variable 
name "location" in the local scope. ...

The above is invalid, and Chris is incorrect in talking about local scope here,
the page does |var location;| in the *global* scope and according to the
ECMAScript spec |var foo| will not override |foo| if |foo| already exists in
that scope. The above is trivial to fix, either rename the variable to something
other than location, or scope the definition of the variable so that it is not
in the global scope, or even if this is nasty, you could add a |delete location|
before the declaration of the "local" location variable.

I don't see this ever being fixed in mozilla.

Comment 10

[Frank Burleigh]

Here's my problem: following the steps I reported in Bug 110310, I do not see
the code that would cause the problem: there is no "location" in that html.  In
other words, I do not see the connection between this bug and the one I
reported--not saying it isn't there, I just need it explained to me.  Maybe the
form submission leads to a page that in turn bombs out, but I can't see that
page; I see the page with the form submission on it (no 'location' there) and
the page announcing the error (no 'location' there, either).  I'm sorry, help???

Comment 11

[Johnny Stenback (:jst)]

If you feel that bug 110310 is unrelated to this bug then please re-open bug
110310 until someone can explain why that bug would be a dup of this one (I'm
not saying it is or isn't, I haven't had a chance to look into that yet).

Comment 12

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 131212 ***