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
