Bug 41705

Summary: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments
Product: Koha Reporter: Martin Renvoize (ashimema) <martin.renvoize>
Component: CirculationAssignee: Martin Renvoize (ashimema) <martin.renvoize>
Status: Failed QA --- QA Contact: Testopia <testopia>
Severity: minor    
Priority: P5 - low CC: andrew, black23, david, fridolin.somers, gmcharlt, koha-bugs, kyle, lisette, martin.renvoize, maryse.simard, sally.healey, testopia
Version: unspecified   
Hardware: All   
OS: All   
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 23228, 23461    
Bug Blocks: 13985    
Attachments: Bug 41705: Upgrade POS receipt printing to use PRG pattern

Description Martin Renvoize (ashimema) 2026-01-24 12:19:12 UTC
The pattern we use for automatically printing receipts and slips can often trigger popup blockers.

This is because we trigger the popup window via JavaScript after page reload and this is interpreted as not being a user directed event and thus invokes many browsers popup blocking code.

We could reverse our process such that the form submission itself has a target="_blank" attribute to trigger the popup at form submission time (which is a direct user action), then our controller handles the post, redirect, get pattern for printing. We fires the window print in the already opened new tab and finally close the tab, thus bringing the original tab back into focus, after print.

This would need a little thought regarding the original tab, as we'd need the reset that tabs context/state as part of the initial submit that triggers the popup earlier in the process.
Comment 1 Martin Renvoize (ashimema) 2026-01-24 16:51:07 UTC
Created attachment 192000 [details] [review]
Bug 41705: Upgrade POS receipt printing to use PRG pattern

This commit implements a POST-Redirect-GET (PRG) pattern for the Point of Sale.
We also reverse the receipt printing workflow to make it popup-safe when using
FinePaymentAutoPopup.

- When FinePaymentAutoPopup is enabled, the POS form submits to a new tab
- The server processes the payment and redirects to the receipt print page
- The receipt page auto-prints and attempts to close itself
- When FinePaymentAutoPopup is disabled, the original in-page flow is preserved
- Added error handling for missing receipts
- Modernized JavaScript printing logic
- Added manual print and close buttons to receipt page

Test Plan:
1. Enable FinePaymentAutoPopup system preference
2. Go to Point of Sale page and complete a sale
3. Confirm the receipt opens in a new tab and auto-prints
4. Close the receipt tab and verify the POS page is ready for next transaction
5. Disable FinePaymentAutoPopup system preference
6. Complete another sale
7. Verify the POS page reloads with 'Print receipt' and 'Email receipt' buttons
8. Click 'Print receipt' and verify it opens in a new tab
9. Test error case: manually modify receipt URL and verify error message displays
Comment 2 David Nind 2026-01-24 18:09:59 UTC
I'm getting these errors:

1. With FinePaymentAutoPopup set to "Do":

Can't locate object method "uri_for" via package "C4::Context" at /kohadevbox/koha/pos/pay.pl line 84.
 at /kohadevbox/koha/pos/pay.pl line 82
 
2. With FinePaymentAutoPopup set to "Don't":

Can't locate object method "uri_for" via package "C4::Context" at /kohadevbox/koha/pos/pay.pl line 92

Testing notes (using KTD):
1. Apply the patch.
2. Rebuild: yarn build
3. Restart: restart_all
4. EnablePointOfSale set to "Enable"
5. UseCashRegisters set to "Use"
6. Create a cash register: Administration > Accounting > Cash registers
7. Add a debit type: Administration > Accounting > Debit types