[whatwg] Browsers delay window.print() action until page load finishes
ian at hixie.ch
Tue Aug 2 16:14:34 PDT 2011
On Wed, 4 May 2011, Alexey Proskuryakov wrote:
> 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,
> <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.
On Wed, 4 May 2011, Boris Zbarsky wrote:
> In Gecko's case if a print operation is pending then further calls to
> print() are effectively ignored.
> 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.
> I _think_ Gecko's current code just aims for "has onload started
I've tried to spec this.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg