[whatwg] Browsers delay window.print() action until page load finishes

[Boris Zbarsky]

On 5/4/11 6:58 PM, Alexey Proskuryakov wrote:
> <script>
> window.print();
> </script>
> <p>Print me</p>
>
> Safari 5 prints a blank page, while other IE and Firefox print "Print me". WebKit nightly builds print "Print me", too.
>
> Notably, we've seen different results in Firefox when printing file: vs. http: documents.

Odd.  The behavior should be pretty consistent: if print() is called 
while the document is loading we delay it to right after onload fires.

> There is a number of subtleties, some of which we know about from a discussion in<https://bugs.webkit.org/show_bug.cgi?id=43658>. E.g. what happens if window.print() is called multiple times during loading

In Gecko's case if a print operation is pending then further calls to 
print() are effectively ignored.

> or if window.close() is called immediately afterwards (which happens on live sites in window.open()/write()/print()/close() scenario).

In Gecko, if window.close() is called while a print operation is pending 
or while printing is in progress (printing is async), the close is 
deferred until the printing stuff is done.  Note that the tab/window the 
user sees may still appear to go away in the meantime, but the internal 
data structures are kept alive until the print operation completes.  Or 
at least that's what the code is trying to do; I haven't tested how it 
works in practice.

> And yes, we only defer window.print() if the document is still "loading" at the time of the call. There are obviously multiple definitions of "loading" possible for this feature.

I _think_ Gecko's current code just aims for "has onload started firing?"

-Boris