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

Discussion in 'Javascript' started by stephen, Dec 23, 2005.

  1. stephen

    stephen Guest

    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, 2005
    1. Advertisements

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

    Thomas 'PointedEars' Lahn, Dec 23, 2005
    1. Advertisements

  3. stephen

    David Wahler Guest

    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

    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

    -- David
    David Wahler, Dec 23, 2005
  4. stephen

    stephen Guest

    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, 2005
  5. stephen

    RobG Guest

    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/ >
    RobG, Dec 24, 2005
  6. stephen

    VK Guest

    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*:

    Unfortunately these listeners still have to be implemented by the
    wannabes. Untill then it is better to leave the content window open.
    VK, Dec 24, 2005
  7. stephen

    RobG Guest

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

    "Prints the current document."


    The Netscape Devedge JS Reference says:

    "Prints the contents of the window."


    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".'


    RobG, Dec 25, 2005
  8. stephen

    VK Guest

    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:

    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.
    VK, Dec 25, 2005
  9. stephen

    RobG Guest

    ? 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

    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.

    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 :) ).

    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.


    It would be interesting to see what happens if the onbeforeprint event
    is 'window.close()';
    RobG, Dec 26, 2005
  10. stephen

    Randy Webb Guest

    RobG said the following on 12/25/2005 11:51 PM:
    IE6.0 Win XP SP2 with this code:

    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 Webb, Dec 26, 2005
  11. stephen

    VK Guest


    window.onafterprint=function(){alert('Print complete!');}
    // 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.
    VK, Dec 26, 2005
  12. Only if we are talking about a PostScript printer.
    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.


    Thomas 'PointedEars' Lahn, Dec 26, 2005
  13. stephen

    bwucke Guest

    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
    bwucke, Dec 26, 2005
  14. stephen

    Randy Webb Guest

    VK said the following on 12/26/2005 8:20 AM:
    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.
    No, it is all about what does system-wise "window.print()" means.
    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 Webb, Dec 26, 2005
  15. stephen

    VK Guest

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

    <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;
    <script type="text/javascript">
    function init() {
    document.documentElement.onlayoutcomplete = stage1;
    window.onbeforeprint = stage2;
    window.onafterprint = stage3;

    function 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() {
    /* 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() {
    /* 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;

    <div id="t1">Test page</div>
    VK, Dec 26, 2005
  16. JRS: In article <>
    , dated Mon, 26 Dec 2005 14:28:42 local, seen in
    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
    Dr John Stockton, Dec 27, 2005
  17. stephen

    RobG Guest

    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.

    RobG, Dec 28, 2005
  18. stephen

    bwucke Guest

    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.
    bwucke, Dec 28, 2005
  19. stephen

    bwucke Guest

    VK napisal(a):
    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?
    bwucke, Dec 28, 2005
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.