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

Discussion in 'Javascript' started by stephen@ploughbooksales.com.au, Dec 23, 2005.

  1. 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
    1. Advertising

  2. 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
    Thomas 'PointedEars' Lahn, Dec 23, 2005
    #2
    1. Advertising

  3. David Wahler Guest

    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
    David Wahler, Dec 23, 2005
    #3
  4. 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
    #4
  5. RobG Guest

    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
    RobG, Dec 24, 2005
    #5
  6. VK Guest

    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.
    VK, Dec 24, 2005
    #6
  7. RobG Guest

    VK wrote:
    > 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
    RobG, Dec 25, 2005
    #7
  8. VK Guest

    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.
    VK, Dec 25, 2005
    #8
  9. RobG Guest

    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
    RobG, Dec 26, 2005
    #9
  10. Randy Webb Guest

    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/
    Randy Webb, Dec 26, 2005
    #10
  11. VK Guest

    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.
    VK, Dec 26, 2005
    #11
  12. 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
    Thomas 'PointedEars' Lahn, Dec 26, 2005
    #12
  13. Guest

    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, 2005
    #13
  14. Randy Webb Guest

    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/
    Randy Webb, Dec 26, 2005
    #14
  15. VK Guest

    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>
    VK, Dec 26, 2005
    #15
  16. JRS: In article <>
    , dated Mon, 26 Dec 2005 14:28:42 local, seen in
    news:comp.lang.javascript, VK <> 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.
    Dr John Stockton, Dec 27, 2005
    #16
  17. RobG Guest

    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
    RobG, Dec 28, 2005
    #17
  18. Guest

    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, 2005
    #18
  19. Guest

    VK napisal(a):
    > 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, 2005
    #19
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fabio R.
    Replies:
    0
    Views:
    781
    Fabio R.
    Mar 25, 2005
  2. UJ
    Replies:
    4
    Views:
    9,656
    =?Utf-8?B?U3JlZWppdGggUmFt?=
    Jul 19, 2005
  3. David Otton

    window.onload and body.onload differences

    David Otton, Nov 4, 2004, in forum: Javascript
    Replies:
    2
    Views:
    535
    Martin Honnen
    Nov 4, 2004
  4. Replies:
    5
    Views:
    251
    Thomas 'PointedEars' Lahn
    May 15, 2005
  5. marco

    onload -->* no onload

    marco, Jun 22, 2006, in forum: Javascript
    Replies:
    7
    Views:
    194
    marco
    Jun 24, 2006
Loading...

Share This Page