226432 - Variables not reset when new document is loaded in window object

Status: VERIFIED INVALID

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

Description

[Hubert Kauker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030

When a script opens a new window and defines a variable in the new window object,
the variable survives when a new document is loaded in the new window.


Reproducible: Always

Steps to Reproduce:
1. var w = window.open();
2. w.foo = 1000;
3. w.location.href = url;
4. alert w.foo when loading is complete

Actual Results:  
Shows 1000.

Expected Results:  
Should have reported 'undefined' value.

Comment 1

[Boris Zbarsky [:bzbarsky]]

www.travelbays.de seems to have no DNS record...  Please attach a testcase here.

Comment 2

[Johnny Stenback (:jst)]

This is as designed. The site opens a new window, which causes about:blank to be
loaded in that new window, then it sets a property on that new window and loads
a webpage into that window, once that page is loaded, it checks for the
property, and it's there. There's a special case in the code that does *not*
reset the window object when *leaving* about:blank, and that's done for
compatibility reasons.

Marking INVALID.

Comment 3

[Hubert Kauker]

1. Sorry about the typing error.
Testcase should be: 
http://www.travelbasys.de/kauker/test/w1.html

2. I'm having rather mixed feelings about "This is as designed..."
Is there any spot in the docs saying that a window containing
the 'about:blank' document is different from any other window
when it comes to leaving it?
It may well be that there is a special case in the CODE, but it that
case justified?
And what may be the compatibility reasons?

Please reopen the bug.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> And what may be the compatibility reasons?

See bug 159424 

Verified invalid.

Comment 5

[Hubert Kauker]

Oh yeah. That's great.
It was very revealing to read comment #27 of Mitchell Stoltz from that bug:

> When window.open is called, save the principal of the calling script in a
> variable on the window being opened. Then, when content arrives and
> SetNewDocument is called, compare the cached principal to the principal of the
> document being loaded. 
> If they match, don't clear the scope. 
> Otherwise, proceed with the existing behavior.

By clearing the scope you probably mean resetting all variables of the global 
object.
Are you sure you really want to maintain this approach? Not resetting the 
global scope under certain conditions???
This definitely introduces another incompatibility among major browsers.
You might care to run my testcase in two other browsers.

By the way. Coding the following sequence:
var w = window.open( url, ... );
w.whatever = "...";

which originally gave rise to the other bug, is definitely bad practice, since 
window.open() is not guaranteed to be a synchronous operation. Or is it?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> By clearing the scope you probably mean resetting all variables

Yes.

> Are you sure you really want to maintain this approach?

Yes, unfrotunately.

> window.open() is not guaranteed to be a synchronous operation. Or is it?

It's not, but it acts like it in some ways in IE.  Hence the problems.

Comment 7

[Hubert Kauker]

> It's not, but it acts like it in some ways in IE.  Hence the problems.

No, you are definitely wrong there.
window.open() never acts like a synchronous operation in IE and IE 
documentation never says it is one.
Quite on the contrary, IE documentation is full of recommendations either
- to check on document.readyState == 'complete' 
- or to let the onload event handler signal completion
before assuming the new document is loaded.
Many book authors and tutorial writers are saying the same.
A very quick research in Google will prove this.

Why should, then, a wrongly posed problem be allowed to influence a sound 
decision?
A sound decision can only be: a new document will ALWAYS reset all variables 
and methods defined in the global object of its host window.
As soon as Mozilla starts to be different from other major browsers,
that's another headache to web authors.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The fact remains that the testcase in bug 159424 works in IE...