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

S

stephen

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
 
T

Thomas 'PointedEars' Lahn

<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
 
D

David Wahler

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
 
S

stephen

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
 
V

VK

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

RobG

VK said:
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>

[...]
 
V

VK

RobG said:
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.
 
R

RobG

VK said:
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()';
 
R

Randy Webb

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



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

VK

Randy said:
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.
 
T

Thomas 'PointedEars' Lahn

VK said:
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
 
B

bwucke

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

Randy Webb

VK said the following on 12/26/2005 8:20 AM:
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.
 
V

VK

Randy said:
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>
 
D

Dr John Stockton

JRS: In article <[email protected]>
, dated Mon, 26 Dec 2005 14:28:42 local, seen in
news:comp.lang.javascript said:
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.
 
R

RobG

VK said:
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.


[...]
 
B

bwucke

VK napisal(a):

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

bwucke

VK napisal(a):
(e-mail address removed) 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?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top