Bug 11014 - Slip Print Problem in Chrome
Summary: Slip Print Problem in Chrome
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: P5 - low major (vote)
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-08 03:59 UTC by David Cook
Modified: 2016-12-05 21:22 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 11014 - Slip Print Problem in Chrome (8.34 KB, patch)
2014-05-21 03:36 UTC, David Cook
Details | Diff | Splinter Review
[PASSED QA] Bug 11014 - Slip Print Problem in Chrome (8.46 KB, patch)
2014-05-30 11:34 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2013-10-08 03:59:55 UTC
Currently, you can print circulation slips in Internet Explorer, Firefox, Chromium, and probably heaps of other browsers but not Chrome. 

When one goes to print a slip in Chrome, a new browser tab is opened, and the "printThenClose" javascript initiates a print. However, instead of using the system dialogue box, it uses a Chrome-specific print preview screen.

Since this preview screen is non-standard, the javascript doesn't even detect it, and it proceeds to close the window.

(Not the most technical description but that's basically what happens.)

Alas, I can't think of any way of getting around this problem. Some research suggests that people use timers or keyboard/mouse movement handlers, but none of those are really optimal strategies for fixing the problem.

Another way of getting around it in Chrome is to open the browser using the "--args --disable-print-preview" flags. That will use the system dialogue (which halts the processing of the Javascript and thus the closing of the window until after the actual print is either initiated or cancelled) instead of the custom print screen.

However, that might be a lot to ask from a lot of users.

I suppose another idea might be to make the printing happen "silently" but then you don't get to choose your printer which is also sub-optimal.

At the moment, the easiest thing is just to use a different browser (like Firefox) for circulation if the library prints slips. But again...not really an optimal solution to the problem.

Just logging it here anyway.
Comment 1 Liz Rea 2014-01-15 00:51:40 UTC
Agreed, this is problematic, I wish chrome did things in a standard way.
Comment 2 Galen Charlton 2014-02-27 18:22:33 UTC
I've tried setting IntranetSlipPrinterJS to the following:

function printThenClose() {
    window.print();
    setTimeout('window.close()', 1); 
}

Testing (print slip, print slip but cancel) appears to work in the following browsers:

Chrome 32.0.1700.107 m on Win7
Firefox 27.0.1 on Win7
IE 11.0.9600.16428 on Win7

It's ugly, but needs must when the devil drives.  I'd appreciate some testing; if this works across a reasonable range of platforms and browsers, it could become the new default.
Comment 3 Galen Charlton 2014-02-27 18:30:34 UTC
(In reply to David Cook from comment #0)
> Since this preview screen is non-standard, the javascript doesn't even
> detect it, and it proceeds to close the window.

Worse, I've observed that when this happens, the Chrome window that initiated the print popup window can simply freeze, force the user to close the tab.
Comment 4 Galen Charlton 2014-02-27 18:31:15 UTC
(In reply to Galen Charlton from comment #3)
> Worse, I've observed that when this happens, the Chrome window that
> initiated the print popup window can simply freeze, force the user to close
> the tab.

And because of that, I'm bumping up the importance to major.
Comment 5 David Cook 2014-02-28 04:02:39 UTC
(In reply to Galen Charlton from comment #2)
> I've tried setting IntranetSlipPrinterJS to the following:
> 
> function printThenClose() {
>     window.print();
>     setTimeout('window.close()', 1); 
> }
> 
> Testing (print slip, print slip but cancel) appears to work in the following
> browsers:
> 
> Chrome 32.0.1700.107 m on Win7
> Firefox 27.0.1 on Win7
> IE 11.0.9600.16428 on Win7
> 
> It's ugly, but needs must when the devil drives.  I'd appreciate some
> testing; if this works across a reasonable range of platforms and browsers,
> it could become the new default.

This solution also works with the following criteria:

Chrome 33.0.1750.117 m on Win8
Firefox 27.0.1 on Win8
IE 11.0.9600.16518 on Win8

Nice one, Galen!
Comment 6 David Cook 2014-05-20 03:08:23 UTC
I have a patch for 3.14, but I'll double-check against master, and post it a bit later today...

Works a treat in any case.
Comment 7 David Cook 2014-05-20 05:03:34 UTC
As per Galen's suggestion in IRC, I'm going to use an INCLUDE to centralize the code so that Koha's staff client respect the system preference "IntranetSlipPrinterJS" more consistently.

http://wiki.koha-community.org/wiki/Setting_up_slip_printer_to_print_silently

It'll also use the timeout, which fixes printing in Chrome without affecting IE or Firefox.

I'm also including a patch for the self-checkout, but it won't use the "IntranetSlipPrinterJS" system preference.
Comment 8 David Cook 2014-05-21 03:36:43 UTC Comment hidden (obsolete)
Comment 9 sandboxes@biblibre.com 2014-05-29 22:53:49 UTC
Patch tested with a sandbox, by Christopher Brannon <cbrannon@cdalibrary.org>
Comment 10 Kyle M Hall 2014-05-30 11:34:06 UTC
Created attachment 28569 [details] [review]
[PASSED QA] Bug 11014 - Slip Print Problem in Chrome

Currently, slips cannot be printed in circulation, members, or the
self check out when using Chrome.

This patch adds a timer of 1ms which allows Chrome's custom code to
prevent "window.close" occuring before the user has dealt with the
print window.

This patch also allows admins to use the 'IntranetSlipPrinterJS'
system preference to override the slip printing code by centralizing
all the slip printing code in slip-print.inc, and including this JS
anywhere it's needed in the staff client.

I haven't used this include in the OPAC SCO but perhaps it would make
sense to do so as well (even if it isn't referred to in the syspref's
name).

_TEST PLAN_
1) Using Chrome on Windows (not sure if this is an issue on other OSes),
try to print a slip in the following locations:

Fines Tab -> Print button
koha-tmpl/intranet-tmpl/prog/en/modules/members/printfeercpt.tt:

Details tab -> Print button -> Print slip || Print quick slip
koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-receipt.tt:

Details tab -> Print button -> Print summary
koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-print.tt:

Fines tab -> Accounts tab -> Print (Manual invoice of $5 sundry)
koha-tmpl/intranet-tmpl/prog/en/modules/members/printinvoice.tt:

Checkout tab -> Print button
koha-tmpl/intranet-tmpl/prog/en/modules/circ/printslip.tt:

Finish button
koha-tmpl/opac-tmpl/bootstrap/en/modules/sco/printslip.tt

2) Note that each time you try to print, a new print page is created
but closed before you have a chance to print.

3) Apply the patch

4) Repeat Step 1

5) Note that the print page now doesn't close until after you've
chosen to print or cancel.

Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 11 Tomás Cohen Arazi 2014-05-30 19:06:02 UTC
Pushed to master.

Thanks David!
Comment 12 Galen Charlton 2014-05-30 19:46:18 UTC
Pushed to 3.16.x.
Comment 13 Fridolin Somers 2014-12-15 16:45:43 UTC
Pushed to 3.14.x, will be in 3.14.12.
Comment 14 David Cook 2016-05-24 07:00:46 UTC
Found a similar problem with the opac cart print bug 16575