Closed Bug 226416 Opened 21 years ago Closed 21 years ago

No way to detect when document loaded with window.open finishes loading

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.6beta

People

(Reporter: hubert.kauker, Assigned: bzbarsky)

References

(
URL
)

Details

Attachments

(2 files)

Like this?
2.15 KB, patch
danm.moz
: review+
jst
: superreview+
asa
: approval1.6b+
Details | Diff | Splinter Review
testcase fun, demonstrating anomalous unload event
2.56 KB, text/html
Details 
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 document is loaded into a new (or existing) frame or window it should be
expected, that a script doing this has a way to discover when that document has
been fully loaded and all its objects are available for use.

Apparently, neither the document property of the new window, nor document.body,
nor document.body.innerHTML all together are capable to do this.

By the way: in Internet Explorer one can use the condition
document.readyState == "complete"
to check on analogous situations.

It is very hard, however, to produce a test case.

So I use a document with a "very long" body containing a script which assigns a
long string to a variable.
I load this document at the same time into two new windows and monitor the
loading progress.
When document, document.body, and document.body.innerHTML seem to indicated that
all is finished, I try to read the 'data' variable from each window, which is
set by the new document.
In most cases I get an 'undefined' value.

Using simpler documents, however, succeeds.

But Mozilla should be a little more deterministic, shouldn't it?



Reproducible: Sometimes

Steps to Reproduce:
1. Load http://www.travelbasys.de/kauker/test/CheckReadyState.html
2.
3.

Actual Results:  
Most of the time, the 'data' variable defined in one of the new windows has an
'undefined' value.

Expected Results:  
The 'data' variable should be defined.
> that a script doing this has a way to discover when that document has
> been fully loaded and all its objects are available for use.

Yeah. It's called "the onload event handler".  Use that, please.

> When document, document.body, and document.body.innerHTML seem to indicated
> that all is finished

None of those indicate anything.  Why would you think that they do?
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Sorry, you misunderstood.
I know fully well the intention and usage of the window.onload() event handler.
It is usually set INSIDE the document being loaded to handle the respective 
event in its 'host' window.

But the problem is: how can a window, say 'A', find out when a document in 
ANOTHER window, say 'B' has been fully loaded and all its objects are usable?

Could you please fill me in with this tiny bit of detail?
If there is no way of window 'A' getting to know this, may be the bug should
be reopened.
I naturally assumed that when 'A' finds that document.body of 'B' is valid, 
then all objects which in some way 'depend' on it are valid as well.
Thanks.

if you have control over the second window:
<body onload="window.loaded=true;"> and check if loaded is set to true in the
child window.
Granted.
When I happen to have control over window two I can do all sorts of things 
there including set up my own onload handler there which tells window one about 
the end of the job.

But what when I can NOT persuade window two to cooperate? When I do not 'own' 
it?

The idea is: 

When I have script code inside a SCRIPT element, nested inside a BODY element, 
nested inside a HTML element, I sort of assume that an 'inner' element becomes 
valid before an 'outer' element.
By becoming 'valid' I mean that the thing can used as specified.
So when document.body becomes valid, a SCRIPT element inside it should have 
become valid before, which means that all script code inside it has been 
successfully parsed and executed, which means that a variable which is a 
property of the window object, after all, can be used by any external method.

By the same token, a SCRIPT element inside the HEAD of a document, should be 
valid as soon as document.getElementsByTagName("script") returns the SCRIPT 
element in its return array.




> I sort of assume that an 'inner' element becomes valid before an 'outer'
> element.

Bad assumption...

> So when document.body becomes valid, a SCRIPT element inside it should have
> become valid before,

document.body becomes defined as soon as we parse the <body> open tag.  Manu
existing pages depend on this.

Note that you can do:

  w = window.open(whatever);
  w.onload = function { /* do something */ }

which involves no control over the contents of the window you are opening.
bz: that would override a possibly already existing onload handler right?
The other way around.  If the opened window sets its own onload handler, it
would override yours.
> document.body becomes defined as soon as we parse the <body> open tag.  

Can't be true. 
Maybe document.body is CREATED when the body tag is parsed.
But it certainly will not be appended to its parent node until the end body is 
parsed.
At that time, however, both the script and the end script tags will have been 
parsed and appended to its parent node, too.
So the question is: when are the assignment statements contained in the script 
executed? Is that possibly in a parallel thread which would need more careful 
synchronization?

> w = window.open(whatever);
> w.onload = function { /* do something */ }

> cb: that would override a possibly already existing onload handler right?

> bz: The other way around.  
> bz: If the opened window sets its own onload handler, it would override yours.

The first case would break the new page.
The second case would make the trick useless.
So let's forget it.


> But it certainly will not be appended to its parent node until the end body is
> parsed.

Ah, but it will.  That's the only way incremental rendering of web pages can
work.  All nodes get appended to the parents as soon as the start tag is parsed;
that way if the interrupt timer fires partway through parsing of a node, we can
incrementally show whatever we've got up to that point.

> when are the assignment statements contained in the script executed?

For an inline script?  Right after the </script> is parsed.

> Is that possibly in a parallel thread which would need more careful
> synchronization?

Not in Mozilla, but yes in some other browsers, iirc (eg Opera).

In any case, this bug, as filed, is still invalid.  None of the methods you were
trying are indicative of anything regarding whether the load of the page is done.
> None of the methods you were trying are indicative of anything regarding 
whether the load of the page is done.

But please: what *IS* indicative whether the load of the page is done?
I do need this for my web application?
I know that in IE, I can use an interval timer timer and periodically check 
whether the condition "document.readyState == 'complete'" has become true.
What can I do in Mozilla?

Use:
   w.addEventListener('load', function() { /* do something */ }, false);
Thank you, Ian. That's very kind.
I suppose you mean

var w = window.open( url, ... );
w.addEventListener('load', function() { /* do something */ }, false);

Right?

But since window.open() is not guaranteed to be a synchronous operation,
you'll be running into serious timing problems here.
You simply do not know, when addEventListener() will be executed.
Is the new document already loaded then or is it not?

In any case I made a test page:
http://www.travelbasys.de/kauker/test/readystateworkaround.html

and it does NOT work. Try yourself.

Hrm. That _should_ work, no? bz?
Yes, that should work, iirc.
bz: Well it does't...

Hubert: Could you file a bug on this?
Ian: yes, I noticed.  That's why I cced danm and jst.  I'd like to hear what
they say, since they're most familiar with this neck of the woods...
IIRC, the problem is that when a window is opened, we load about:blank
(synchronously, IIRC), and then when the actual document comes in off the
network, we clear event handlers (as we're supposed to) and start over. This
special case needs to be taken into account here, but it's not...
Yup. The w.addEventListener('load',...) in your example is attached to the bogus
preliminary document after it has finished loading. Then the load event listener
is cleared out just before the real contents are loaded, so it never fires.

This means, and I just tried this, that you can get what you want with an unload
listener. Yeah, that's pretty messed up.
Hmm...  so what do we want to do?  Do we want to clear all listeners except
onload listeners?  Or do we want to leave all listeners when going from
about:blank to a page with the same principal as the opener (like we currently
do with the JS scope)?
Reopening and resummarizing to reflect the real issue.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: The document, document.body, and document.body.innerHTML properties do not indicate reliably when a document is fully loaded and all its objects are available to scripting. → No way to detect when document loaded with window.open finishes loading
Or maybe just not clear event listeners on the window at all when leaving
about:blank, i.e. tie that code into the code that does JS_ClearScope()...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Right.  Should it be subject to all the same conditions (non-chrome document,
same security principal, leaving about:blank)?  Or just "don't clear if leaving
about:blank"?
IMO it should be subject to all the same conditions.
Attached patch Like this? — — Splinter Review 

    
  

        Attachment #136275 -
        Flags: superreview?(jst)

        Attachment #136275 -
        Flags: review?(danm-moz)

    
    

    
  
Comment on attachment 136275 [details] [diff] [review]
Like this?

Yeah, looks good.

        Attachment #136275 -
        Flags: superreview?(jst) → superreview+

    
    

    
  
I just filed a bug (226703) as suggested by Hixie in comment #16.
See http://bugzilla.mozilla.org/show_bug.cgi?id=226703.

May I draw your attentation to another thread
http://bugzilla.mozilla.org/show_bug.cgi?id=226432

Here the question "what should be reset when a new document is loaded"
is already under discussion.

Depends on: 226703

    
    

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

    
    

    
  
Comment on attachment 136275 [details] [diff] [review]
Like this?

Looks good to me. Note this is an improvement but we're still not quite there.
It would be better if event listeners on the temporary about:blank bogodocument
were deaf. We still get an anomalous unload event while loading a window's
first document (comment 19).

Note of possible historical interest: we didn't RemoveAllListeners for any
about:blank document for a very long time until rev 1.449 (Oct 2001) for bug
18553. This patch would seem to be a better version of that one.

        Attachment #136275 -
        Flags: review?(danm-moz) → review+

    
    

    
  
Comment on attachment 136275 [details] [diff] [review]
Like this?

Could this please be approved for 1.6b?

        Attachment #136275 -
        Flags: approval1.6b?

    
    

    
  


  
It was too much fun to write not to post. Though it doesn't add much that we
didn't already know. Note it behaves much better with the patch applied, but
the unload is of course still there.

(The festival of focus events has already been noted; that's bug 164686.)

    
    

    
  
Does this allow one site to determine how long it takes another site to load, or
are there cross-site scripting checks in the patch?

    
    

    
  
There are cross-site scripting checks in the patch.

    
    

    
  
Comment on attachment 136275 [details] [diff] [review]
Like this?

a=asa (on behalf of drivers) for checkin to 1.6beta

        Attachment #136275 -
        Flags: approval1.6b? → approval1.6b+

    
  
Assignee: general → bz-vacation
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.6beta

    
    

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

    
    

    
  
Fixed for 1.6b.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED

    
    

    
  
Just out of interest, does this patch actually solve the problem the reporter 
was asking about, or does detecting document loads still involve a race 
condition?

From comment 13:
1: var w = window.open( url, ... );
/* start loading */
/* finish loading */
2: w.addEventListener('load', function() { /* do something */ }, false);

If the document completes loading after line 1, but before line 2 has had a 
chance to add the event listener, will the event listener fire?

Or are we suggesting that since the document load takes /such/ a long time to 
(asynchronously) complete - relative to the time that window.open takes to 
return - that there's virtually no chance that the load could complete before 
line 2 has finished executing?

    
    

    
  
All loads (except for the initial load of about:blank) are asynchonous and
essentially happen on the main thread (the same thread that the JS is running
on), so there is no possibility of a race there, unless the two lines of code
run off of different timers, or cause mozilla to spin a sub-event loop (by
performing synchronous IO, or opening modal dialogues).

    
    

    
  
So the JS execution actually blocks the load? If I do:

var w = window.open( url, ... );
really_slow_function();

Will the window not commence loading until really_slow_function returns?


    
    

    
  
If the function just runs and doesn't put up any modal dialogs or make any
disk/network I/O requests, yes.

    
    

    
  
(The anomalous unload event (comment 19, comment 29) is bug 197709).

    
    

    
  
I missed all the fun.

The use of a blank bogo-document seems to be the root of much evil.  Why is that
necessary?  It wasn't in the ancient (Nav2 and on) daze, when I made sure (a)
you could preset onload after window.open, which by definition is asynch; and
(b) no bogo-doc was loaded synchronously, to generate spurious unload or other
events.

/be

    
    

    
  
about:blank bogodocument's raison d'etre is the subject of new bug 227028.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: