[whatwg] Browsers delay window.print() action until page load finishes
ap at webkit.org
Wed May 4 15:58:35 PDT 2011
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:
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
More information about the whatwg