By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 1,552 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

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

P: n/a
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?

Thank you in advance,

Stephen

Dec 23 '05 #1
Share this Question
Share on Google+
22 Replies


P: n/a
st*****@ploughbooksales.com.au wrote:
<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?


You are trying to close the window that displays the document you want to
print.
PointedEars
Dec 23 '05 #2

P: n/a
st*****@ploughbooksales.com.au wrote:
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"


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

Dec 23 '05 #3

P: n/a
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

Dec 24 '05 #4

P: n/a
st*****@ploughbooksales.com.au wrote:
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.


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
Dec 24 '05 #5

P: n/a
On 2005-12-23, st*****@ploughbooksales.com.au <st*****@ploughbooksales.com.au> wrote:
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?


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
Dec 24 '05 #6

P: n/a
VK

st*****@ploughbooksales.com.au wrote:
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?


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*:
onlayoutcomplete
onberoreprint
onafterprint

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

Dec 24 '05 #7

P: n/a
VK wrote:
st*****@ploughbooksales.com.au wrote:
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?

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.


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

"Prints the current document."

<URL:http://developer.mozilla.org/en/docs/DOM:window.print>
The Netscape Devedge JS Reference says:

"Prints the contents of the window."

<URL:http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1203138>
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#dt-DOM-Level-0>

[...]
--
Rob
Dec 25 '05 #8

P: n/a
VK

RobG wrote:
VK wrote:
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.


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

"Prints the current document."

<URL:http://developer.mozilla.org/en/docs/DOM:window.print>
The Netscape Devedge JS Reference says:

"Prints the contents of the window."

<URL:http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1203138>


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.print() 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.print() 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.print();
windowObject.close();

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.

Dec 25 '05 #9

P: n/a
VK wrote:
RobG wrote:
VK wrote:
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.
Maybe that is your opinion based on one browser. The Mozilla DOM
reference says that window.print():

"Prints the current document."

<URL:http://developer.mozilla.org/en/docs/DOM:window.print>
The Netscape Devedge JS Reference says:

"Prints the contents of the window."

<URL:http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/window.html#1203138>

I'm ususally trying to avoid rude comments, but both quoted definitions
are bs^2


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

which brings us back to the discussion of benefits and
drawbacks of wiki'ed manuals.
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.

windowObject.print() 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?
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 :-) ).

[...]
The only reason it works (sometimes!) in IE - is that IE as usual makes
extra step to try to understand user's intentions.
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.

[...]
- but IE does it on its
own behalf and not obligated by any standards.


Exactly.

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

--
Rob
Dec 26 '05 #10

P: n/a
RobG said the following on 12/25/2005 11:51 PM:
VK wrote:


<snip>
The only reason it works (sometimes!) in IE - is that IE as usual makes
extra step to try to understand user's intentions.

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.


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 26 '05 #11

P: n/a
VK

Randy Webb wrote:
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.


try:

window.onafterprint=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.

Dec 26 '05 #12

P: n/a
VK wrote:
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.
True.
It simply means that the system is done with preparing PostScript'ed
Only if we are talking about a PostScript printer.
screenshot
Huh?
of the document and that it sent to hell (print manager) knows where.


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.org/wiki/Computer_printer>
PointedEars
Dec 26 '05 #13

P: n/a

st*****@ploughbooksales.com.au wrote:
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.


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.

Dec 26 '05 #14

P: n/a
VK said the following on 12/26/2005 8:20 AM:
Randy Webb wrote:
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.

try:

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


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.onafterprint but it doesn't
wait on window.print() as the code I posted shows that it doesn't.
It is all about what does system-wise "print is done" means.
No, it is all about what does system-wise "window.print()" 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.


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.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Dec 26 '05 #15

P: n/a
VK

Randy Webb wrote:
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.


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.


Maybe a working sample may help (naturally IE only, try either
File>Print or File>Print preview).

<html>
<head>
<title>Print</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
@media screen {
div {
font: bold 10pt Verdana, Geneva, sans-serif;
color: #000099;
}
body {
background-color: #FFFF99;
}
}
@media print {
div {
font: bold 10pt Verdana, Geneva, sans-serif;
color: #000000;
}
body {
background-color: #FFFFFF;
}
}
</style>
<script type="text/javascript">
function init() {
document.documentElement.onlayoutcomplete = stage1;
window.onbeforeprint = stage2;
window.onafterprint = stage3;
setTimeout('window.print()');
}

function stage1() {
alert('stage1');
/* On this stage browser defines what document
* to print (because an alternate document can be defined).
* It also prepare print template using defined LayoutRect if any.
* For databound elements actual value corresponding to
* the applied filters is retrieved.
* As nothing of this is presented in this sample, this event
* is not fired on HTML element.
*/
}

function stage2() {
alert('stage2');
/* On this stage browser prepares actual
* print layout. If media-specific styles are
* supplied (like in this sample) browser switches
* the "document image" from screen-styles to print-styles.
* After all this done the describing event is fired
* so you could make any last-minute DOM damages :-)
* if you need too.
* After that PostScript "screenshot" is made and sent
* to the print pool.
*/
}

function stage3() {
alert('stage3');
/* The last bit of the PostScript stuff went to the pool.
* If any changes have been made on beforeprint,
* here is your chance to undo them for normal
* screen view.
*/
}

if (window.onbeforeprint === null) {
window.onload = init;
}
</script>
</head>

<body>
<div id="t1">Test page</div>
</body>
</html>

Dec 26 '05 #16

P: n/a
JRS: In article <11**********************@o13g2000cwo.googlegroups .com>
, dated Mon, 26 Dec 2005 14:28:42 local, seen in
news:comp.lang.javascript, VK <sc**********@yahoo.com> posted :
Maybe a working sample may help (naturally IE only, try either
File>Print or File>Print preview). <style type="text/css">
@media screen {
div {
font: bold 10pt Verdana, Geneva, sans-serif;
color: #000099;
}
body {
background-color: #FFFF99;
}
}


Please do not recommend code which sets a fixed point size (except in
unusual circumstances).

Fixing point size is bad practice in general, can be illegal, and is
amateurish.

--
John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Dec 27 '05 #17

P: n/a
VK wrote:

Maybe a working sample may help (naturally IE only, try either
File>Print or File>Print preview).


And there is the point I was making. window.print() works differently
on different platforms and also (it seems) sometimes differently on
the same platform depending on the context.

The real issue is that in the OP's case, window.print() need not
(probably should not) be used at all, a print medium style sheet is a
better solution.
[...]
--
Rob
Dec 28 '05 #18

P: n/a
VK

RobG wrote:
The real issue is that in the OP's case, window.print() need not
(probably should not) be used at all, a print medium style sheet is a
better solution.


Bingo!

Dec 28 '05 #19

P: n/a

VK napisal(a):
RobG wrote:
The real issue is that in the OP's case, window.print() need not
(probably should not) be used at all, a print medium style sheet is a
better solution.


Bingo!


Actually putting a neat "print" icon disabled by media-specific style
sheet in printout and linked to window.print() is a polite thing to do.
Closing the window just after clicking that icon, straight opposite.

Dec 28 '05 #20

P: n/a
VK

bw****@gmail.com wrote:
Actually putting a neat "print" icon disabled by media-specific style
sheet in printout and linked to window.print() is a polite thing to do.
Closing the window just after clicking that icon, straight opposite.


media specific styles are always the best solution (unless required to
support pre-historic browsers).
The only implication I can think of - if it's not a WYSIWIP (What You
See Is What You Print). Say you click to print bill statement which is
not currently displayed on the page but coming as server response upon
click. I guess in this situation (which I *personally* consider to be a
bad interface design) one could query for page using AJAX, place it in
dyncreated iframe, set focus on it and iframeObject.print(). It is
still much better and convenient than depend on popups and execution
order.

Dec 28 '05 #21

P: n/a

VK napisal(a):
bw****@gmail.com wrote:
The only implication I can think of - if it's not a WYSIWIP (What You
See Is What You Print). Say you click to print bill statement which is
not currently displayed on the page but coming as server response upon
click. I guess in this situation (which I *personally* consider to be a
bad interface design) one could query for page using AJAX, place it in
dyncreated iframe, set focus on it and iframeObject.print(). It is
still much better and convenient than depend on popups and execution
order.


Well, what you see is often what you don't want to print, especially if
it's no longer a "webpage" but an "ajax application". In this case
styles may be far away from what you want to achieve and creating a
separate page with printout seems to be the right way to go.
But then forcing printing immediately is rather rude. Let the user
preview the page, check if it's really what they want printed. Let them
change page properties in the menu, trim margins to save paper, change
headers/footers attached by the browser, decide if they want to print
all that is shown or just one-two pages or a highlighted paragraph.
Then let them click a conveniently placed "print" button and have the
page printed. And then leave it open in case they wanted to print some
other paragraph, or decided they want another copy. Let them close it
at their leisure. You may make it more convenient by providing an extra
button, to close the printout page, but don't force closing it just
after the user clicked "print".
By the way, not once I found myself clicking "print-friendly version"
and just -reading- (without ever printing) the text of the article in
the popup, simply because it is way more reader-friendly than often
awfully mangled interface found on portals/newspapers/blogs.
Is there a handy way to enforce rendering the page according to @media
print{} stylesheets in the browser window?

Dec 28 '05 #22

P: n/a
VK

bw****@gmail.com wrote:
Is there a handy way to enforce rendering the page according to @media
print{} stylesheets in the browser window?


There is but like the first DHTML's - idea is the same but the code is
very browser specific.

You can switch applied stylesheets. Some browsers support "alternate
stylesheet" type, so all sheets with "title" attrubute set go to
special drop-down select list.

The only browser which is out of the loop is Opera. Until now they fail
to implement CSS2 methods (except a couple).

Dec 28 '05 #23

This discussion thread is closed

Replies have been disabled for this discussion.