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

04.05.2011, ? 15:38, Ian Hickson ???????(?):

>> There seems to be no provision in the spec for a behavior Firefox and IE 
>> (and now WebKit-based browsers, too) have. If window.print() is called 
>> during page load, then its action is delayed until loading is finished.
> 
> I haven't been able to reproduce this. I can reproduce cases where the 
> browser entirely ignores a window.print() call (as allowed by the spec), 
> but none where the call is delayed until later.
> 
> Do you have a test case demonstrating this?

Yes - for example, <http://leiz.org/chromium/25027.htm>. Basically, it's:

<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.

> I'd be happy to spec this, I'm just trying to work out what it means with 
> respect to event firing, etc (the rest of the algorithm). Presumably, in 
> many cases we want it to be synchronous as now, since pages presumably 
> depend on being able to edit the DOM before and after.


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, or if window.close() is called immediately afterwards (which happens on live sites in window.open()/write()/print()/close() scenario).

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.

- WBR, Alexey Proskuryakov

Received on Wednesday, 4 May 2011 15:58:35 UTC