[whatwg] Browsers delay window.print() action until page load finishes
bzbarsky at MIT.EDU
Wed May 4 17:12:29 PDT 2011
On 5/4/11 6:58 PM, Alexey Proskuryakov wrote:
> <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?"
More information about the whatwg