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

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

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 
> firing?"

I've tried to spec this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 2 August 2011 16:14:34 UTC