https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Bug ID: 42505 Summary: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle@bywatersolutions.com When returning an item required to fulfil a hold at another branch, with HoldsAutoFill set to 'Don't', the 'Hold found' modal (returns.tt: hold-found-modal / hold-found2 in older versions) is displayed and the librarian must choose 'Confirm hold and transfer' or 'Print slip, transfer, and confirm'. If the librarian clicks the print variant, the slip is opened via window.open() (Dopop()) called from $(document).ready on the page that loads *after* the form submission to confirm the hold. Because the window.open() call happens during a fresh page load, it is not associated with a user gesture, and modern browsers block it as an unsolicited popup. This affects the same code path used for HoldsAutoFill + HoldsAutoFillPrintSlip: the slip popup is fired on document.ready of the response page, with the same popup-blocker risk. Steps to reproduce ================== 1. Set HoldsAutoFill = Don't. 2. Place a hold for a patron with a pickup branch different from the staff member's logged-in branch. 3. Check in the item at the staff member's branch. 4. The 'Hold found' modal appears. 5. Click 'Print slip, transfer, and confirm'. Expected: the hold is confirmed and the hold transfer slip opens in a new window. Actual: the form submits and the hold is confirmed, but the slip popup is blocked by the browser. The librarian sees no slip and may not realise the slip was attempted. Root cause ========== In koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt the .print click handler sets a hidden input print_slip=1 and submits the form. The server (circ/returns.pl) sets the print_slip template parameter on the response, and the response page calls Dopop() (window.open) on document.ready. That window.open() is not within a user gesture event, so popup blockers reject it. Suggested fix ============= Open the print window synchronously inside the .print click handler, while the user gesture is still active. The reserve_id is already present in the modal form as a hidden input, and hold-transfer-slip.pl needs only the reserve_id; the slip content does not depend on the hold having been moved to Waiting state. The form submit to confirm the hold then proceeds in the main window as before. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.