<body onload="window.print(); window.close();">

**Thomas 'PointedEars' Lahn** · Dec 23 '05, 04:15 PM

Re: <body onload="wi ndow.print(); window.close(); ">

stephen@ploughb ooksales.com.au wrote:
[color=blue]
> <body onload="window. print(); window.close(); ">
>
> This works correctly (or at least the way I expect it to work under MS
> Internet Explorer, but it cuases Netscape to "crash"
>
> Does anyone have an explanation as to why?[/color]

You are trying to close the window that displays the document you want to
print.

PointedEars

**David Wahler** · Dec 23 '05, 08:25 PM

Re: <body onload="wi ndow.print(); window.close(); ">

stephen@ploughb ooksales.com.au wrote:[color=blue]
> I have created an order form that users javascript to create a new html
> document when the customers clicks the "print page" button.
>
> Once the new document has been created it then prints the document and
> closes it with the following code:
>
> <body onload="window. print(); window.close(); ">
>
> This works correctly (or at least the way I expect it to work under MS
> Internet Explorer, but it cuases Netscape to "crash"[/color]

My testing in Firefox 1.5 seems to indicate that window.print is
asynchronous; that is, the script does not wait for the dialog box to
be closed before continuing. For example, if you change your onload
handler to the following:

<body onload="window. print(); alert('foo');">

....then Firefox will show the "foo" alert first, and then the Print
dialog.

Unfortunately, it seems that window.print has never been part of any
formal specification, so it's meaningless to ask whether being
synchronous or asynchronous is the "correct" behavior. However, it's
pretty obvious that no matter what, it shouldn't be able to crash the
browser.

-- David

**stephen@ploughbooksales.com.au** · Dec 24 '05, 12:25 AM

Re: <body onload="wi ndow.print(); window.close(); ">

Thanks for the explanations.

So is there a way of closing the document after it has been printed, or
can I only leave it there is an artifact for the customer to close.

Stephen

**RobG** · Dec 24 '05, 01:05 AM

Re: <body onload="wi ndow.print(); window.close(); ">

stephen@ploughb ooksales.com.au wrote:[color=blue]
> Thanks for the explanations.
>
> So is there a way of closing the document after it has been printed, or
> can I only leave it there is an artifact for the customer to close.[/color]

There is no need to create a 'print friendly' version in a separate
window at all, or even use JavaScript - use a print-medium style sheet:

<URL: http://www.alistapart.com/stories/goingtoprint/ >

--
Rob

**Jasen Betts** · Dec 24 '05, 03:25 AM

Re: <body onload="wi ndow.print(); window.close(); ">

On 2005-12-23, stephen@ploughb ooksales.com.au <stephen@plough booksales.com.a u> wrote:[color=blue]
> I have created an order form that users javascript to create a new html
> document when the customers clicks the "print page" button.
>
> Once the new document has been created it then prints the document and
> closes it with the following code:
>
><body onload="window. print(); window.close(); ">
>
> This works correctly (or at least the way I expect it to work under MS
> Internet Explorer, but it cuases Netscape to "crash"
>
> Does anyone have an explanation as to why?[/color]

if window.print() is executes asynchronously the page
is unloaded before it can be printed...

sounds like a bug in Netscape to me.

FWIW it works fine in Mozilla

Bye.
Jasen

VK · Dec 24 '05, 01:35 PM

Re: <body onload="wi ndow.print(); window.close(); ">

stephen@ploughb ooksales.com.au wrote:[color=blue]
> I have created an order form that users javascript to create a new html
> document when the customers clicks the "print page" button.
>
> Once the new document has been created it then prints the document and
> closes it with the following code:
>
> <body onload="window. print(); window.close(); ">
>
> This works correctly (or at least the way I expect it to work under MS
> Internet Explorer, but it cuases Netscape to "crash"
>
> Does anyone have an explanation as to why?[/color]

window.print() is not a *process*, it is simply a request to display
print dialog (same as choosing File > Print). Therefore ideas of sync /
async are not applicable here.

IE has full set of event listeners to fine tune the printing *process*:
onlayoutcomplet e
onberoreprint
onafterprint

Unfortunately these listeners still have to be implemented by the
wannabes. Untill then it is better to leave the content window open.

**RobG** · Dec 25 '05, 07:35 AM

Re: <body onload="wi ndow.print(); window.close(); ">

VK wrote:[color=blue]
> stephen@ploughb ooksales.com.au wrote:
>[color=green]
>>I have created an order form that users javascript to create a new html
>>document when the customers clicks the "print page" button.
>>
>>Once the new document has been created it then prints the document and
>>closes it with the following code:
>>
>><body onload="window. print(); window.close(); ">
>>
>>This works correctly (or at least the way I expect it to work under MS
>>Internet Explorer, but it cuases Netscape to "crash"
>>
>>Does anyone have an explanation as to why?[/color]
>
>
> window.print() is not a *process*, it is simply a request to display
> print dialog (same as choosing File > Print). Therefore ideas of sync /
> async are not applicable here.[/color]

Maybe that is your opinion based on one browser. The Mozilla DOM
reference says that window.print():

"Prints the current document."

<URL:http://developer.mozil la.org/en/docs/DOM:window.prin t>

The Netscape Devedge JS Reference says:

"Prints the contents of the window."

<URL:http://devedge-temp.mozilla.or g/library/manuals/2000/javascript/1.3/reference/window.html#120 3138>

I think the important thing here is that window.print() is DOM 0[1],
and therefore how it works is implementation dependent. You can't
state categorically what it is or does because there is no common
specification that states what it should do, though you might be able
to state what it does in regard to a particular browser.

There are some browsers that don't implement it at all. The best
solution for the OP is to offer a print medium style sheet. If the
browser supports it, it will be used. If not, the window will be
printed as-is.

The use of script in this case is simply not required, there are
already a number of ways to print the page, why add another
(unreliable) method?

1. DOM 0 'refers to a mix (not formally specified) of HTML document
functionalities offered by Netscape Navigator version 3.0 and
Microsoft Internet Explorer version 3.0. In some cases, attributes
or methods have been included for reasons of backward compatibility
with "DOM Level 0".'

<URL:http://www.w3.org/TR/DOM-Level-2-HTML/glossary.html#d t-DOM-Level-0>

[...]

--
Rob

VK · Dec 25 '05, 11:55 AM

Re: <body onload="wi ndow.print(); window.close(); ">

RobG wrote:[color=blue]
> VK wrote:[color=green]
> > window.print() is not a *process*, it is simply a request to display
> > print dialog (same as choosing File > Print). Therefore ideas of sync /
> > async are not applicable here.[/color]
>
> Maybe that is your opinion based on one browser. The Mozilla DOM
> reference says that window.print():
>
> "Prints the current document."
>
> <URL:http://developer.mozil la.org/en/docs/DOM:window.prin t>
>
>
> The Netscape Devedge JS Reference says:
>
> "Prints the contents of the window."
>
> <URL:http://devedge-temp.mozilla.or g/library/manuals/2000/javascript/1.3/reference/window.html#120 3138>[/color]

I'm ususally trying to avoid rude comments, but both quoted definitions
are bs^2 - which brings us back to the discussion of benefits and
drawbacks of wiki'ed manuals.

windowObject.pr int() is nothing but GUI call and it never was anything
else, and it never be anything else for security reasons (print 10,000
copies of current page - would you like it?)

windowObject.pr int() simply displays the dialog where user can press
"Yes" - and it starts the printing *process*, or user can press
"Cancel" - and it will be the end of the story (the *process* will
never start).

In the case of:
windowObject.pr int();
windowObject.cl ose();

script execution halts after the first statement as for any modal
dialog. After the modal dialog is closed nothing prevents the script to
execute the second statement, no matter if user pressed Yes or Cancel.

The only reason it works (sometimes!) in IE - is that IE as usual makes
extra step to try to understand user's intentions. In the particular it
guesses that if windowObject is chosen to be printed, then it shouldn't
be destroyed at least until print job is prepared and sent to the
printer. It is a very helpful formal reasonning - but IE does it on its
own behalf and not obligated by any standards.

**RobG** · Dec 26 '05, 05:05 AM

Re: <body onload="wi ndow.print(); window.close(); ">

VK wrote:[color=blue]
> RobG wrote:
>[color=green]
>>VK wrote:
>>[color=darkred]
>>>window.print () is not a *process*, it is simply a request to display
>>>print dialog (same as choosing File > Print). Therefore ideas of sync /
>>>async are not applicable here.[/color]
>>
>>Maybe that is your opinion based on one browser. The Mozilla DOM
>>reference says that window.print():
>>
>> "Prints the current document."
>>
>><URL:http://developer.mozil la.org/en/docs/DOM:window.prin t>
>>
>>
>>The Netscape Devedge JS Reference says:
>>
>> "Prints the contents of the window."
>>
>><URL:http://devedge-temp.mozilla.or g/library/manuals/2000/javascript/1.3/reference/window.html#120 3138>[/color]
>
>
> I'm ususally trying to avoid rude comments, but both quoted definitions
> are bs^2[/color]

? They are descriptions of what window.print does from a certain point
of view. My intention was to show that different browsers have
different ideas of what it does and that it is not controlled by any
standard.

[color=blue]
> which brings us back to the discussion of benefits and
> drawbacks of wiki'ed manuals.[/color]

That is irrelevant. Devedge isn't a wiki, the Mozilla wiki
documentation does not allow anonymous entries, though there is no
restriction on who may open an account so it's scant control but it
does seem to have worked OK so far.

If you don't like the Mozilla entry, update it.

[color=blue]
> windowObject.pr int() is nothing but GUI call and it never was anything
> else, and it never be anything else for security reasons (print 10,000
> copies of current page - would you like it?[/color]

If someone wanted to create a browser that did that, then so be it but
it would be a rather nasty feature. Word and Excel both have buttons
on their toolbars that send documents directly to the printer without
displaying a dialog. Both support scripting that allows a script to
submit documents directly to the printer too. Clearly somebody thinks
it's a good idea in some cases.

But in any case, it's irrelevant. This discussion isn't about why
window.print works as it does, it's that you consider it to have only
one defined process. My point was that there isn't one (though
Netscape's crashing is a rather disappointing why of handling the
situation :-) ).

[...]
[color=blue]
> The only reason it works (sometimes!) in IE - is that IE as usual makes
> extra step to try to understand user's intentions.[/color]

Hardly. IE appears to do exactly what Firefox does - it waits for the
outcome of the print dialog before proceeding with the script which
would appear to be the logical thing to do.

[...]
[color=blue]
> - but IE does it on its
> own behalf and not obligated by any standards.[/color]

Exactly.

It would be interesting to see what happens if the onbeforeprint event
is 'window.close() ';

--
Rob

**Randy Webb** · Dec 26 '05, 01:05 PM

Re: <body onload="wi ndow.print(); window.close(); ">

RobG said the following on 12/25/2005 11:51 PM:[color=blue]
> VK wrote:[/color]

<snip>
[color=blue][color=green]
>> The only reason it works (sometimes!) in IE - is that IE as usual makes
>> extra step to try to understand user's intentions.[/color]
>
>
> Hardly. IE appears to do exactly what Firefox does - it waits for the
> outcome of the print dialog before proceeding with the script which
> would appear to be the logical thing to do.[/color]

IE6.0 Win XP SP2 with this code:

window.print();
alert('window.p rint complete');

I get that alert before I get the window.print window. So IE doesn't
wait for the outcome of window.print() to move on.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

VK · Dec 26 '05, 01:35 PM

Re: <body onload="wi ndow.print(); window.close(); ">

Randy Webb wrote:[color=blue]
> IE6.0 Win XP SP2 with this code:
>
> window.print();
> alert('window.p rint complete');
>
>
> I get that alert before I get the window.print window. So IE doesn't
> wait for the outcome of window.print() to move on.[/color]

try:

window.onafterp rint=function() {alert('Print complete!');}
window.print();
// and press Yes in the dialog
// next time press No

It is all about what does system-wise "print is done" means. It is very
rarely means that the last sheet came out of the printer. It simply
means that the system is done with preparing PostScript'ed screenshot
of the document and that it sent to hell (print manager) knows where.

**Thomas 'PointedEars' Lahn** · Dec 26 '05, 01:45 PM

Re: <body onload="wi ndow.print(); window.close(); ">

VK wrote:
[color=blue]
> It is all about what does system-wise "print is done" means. It is
> very rarely means that the last sheet came out of the printer.[/color]

True.
[color=blue]
> It simply means that the system is done with preparing PostScript'ed[/color]

Only if we are talking about a PostScript printer.
[color=blue]
> screenshot[/color]

Huh?
[color=blue]
> of the document and that it sent to hell (print manager) knows where.[/color]

Probably you mean by that that either the print job has been spooled to the
local buffer of the printer driver, or the local print queue has been
cleared of the respective print job and so, if possible, the respective
print queue of a print server or the memory of the printer has been filled
with it.

<URL:http://en.wikipedia.or g/wiki/Computer_printe r>

PointedEars

**bwucke@gmail.com** · Dec 26 '05, 02:05 PM

Re: <body onload="wi ndow.print(); window.close(); ">

stephen@ploughb ooksales.com.au wrote:[color=blue]
> Thanks for the explanations.
>
> So is there a way of closing the document after it has been printed, or
> can I only leave it there is an artifact for the customer to close.
>[/color]

Possibly not the only thing to do, but the sensible thing to do. And
not disabling the menu.

The user clicks "print" on your previous page. Then they get preview of
what will be printed - your window. Now they can select from the File
menu "Print preview" and check that last few lines overflow to the next
page. Then they select "Page properties" and reduce margins. Then
"Print preview" again, it all fits in one page nicely. Now "Print", the
paper got jammed, have to print again. "Print", nice. A friend comes by
and asks for a copy. "Print" again.

Your solution is rude. Don't treat your users like idiots. It offends
them.

**Randy Webb** · Dec 26 '05, 10:05 PM

Re: <body onload="wi ndow.print(); window.close(); ">

VK said the following on 12/26/2005 8:20 AM:[color=blue]
> Randy Webb wrote:
>[color=green]
>>IE6.0 Win XP SP2 with this code:
>>
>>window.print( );
>>alert('window .print complete');
>>
>>
>>I get that alert before I get the window.print window. So IE doesn't
>>wait for the outcome of window.print() to move on.[/color]
>
>
> try:
>
> window.onafterp rint=function() {alert('Print complete!');}
> window.print();
> // and press Yes in the dialog
> // next time press No[/color]

That is not what RobG said that I quoted that you snipped. Let me quote
it again for you:

"IE appears to do exactly what Firefox does - it waits for the outcome
of the print dialog before proceeding with the script which would appear
to be the logical thing to do."

And IE does _not_ wait for the results of window.print() before
continuing. It may or may not wait on window.onafterp rint but it doesn't
wait on window.print() as the code I posted shows that it doesn't.
[color=blue]
> It is all about what does system-wise "print is done" means.[/color]

No, it is all about what does system-wise "window.print() " means.
[color=blue]
> It is very rarely means that the last sheet came out of the printer.
> It simply means that the system is done with preparing PostScript'ed
> screenshot of the document and that it sent to hell (print manager)
> knows where.
>[/color]

I don't think I want to give myself a headache trying to understand what
you just attempted to say as it doesn't make any sense at all.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

<body onload="window.print(); window.close();">

<body onload="window.print(); window.close();">

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment