[Bug 42505] New: Hold transfer slip popup blocked by browser after 'Print slip and confirm' is clicked on hold-found modal
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.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198402 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198402&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: West Sussex Library Service Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Comma delimited| |OpenFifth list of Sponsors| |<https://openfifth.co.uk/> Status|NEW |Needs Signoff Patch complexity|--- |Trivial patch Sponsorship status|--- |Sponsored -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198402|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #2 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 198403 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198403&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42506 Blocks| |42507 Status|Needs Signoff |Signed Off Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42506 [Bug 42506] Hold transfer slip popup blocked when HoldsAutoFill auto-confirms a hold on check-in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42507 [Bug 42507] Recall pickup slip popup blocked by browser after 'Print slip and confirm' is clicked on recall modal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198403|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #3 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 199178 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199178&action=edit Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted. This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct. To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA CC| |lucas@bywatersolutions.com --- Comment #4 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Martin Renvoize (ashimema) from comment #3)
Created attachment 199178 [details] [review] Bug 42505: Open hold transfer slip in user gesture to bypass popup blocker
When returning an item required to fulfil a hold at another branch with HoldsAutoFill set to "Don't", the librarian is shown a "Hold found" modal and chooses "Print slip, transfer, and confirm". The previous implementation set a hidden 'print_slip' input to 1, submitted the form, and relied on $(document).ready on the response page to call Dopop() / window.open() to open the slip. Because that window.open() is no longer associated with a user gesture (the gesture chain is broken by the form submission and page navigation), modern browsers block it as an unsolicited popup. The hold is confirmed but the slip never appears, and the librarian may not realise it was attempted.
This patch opens the slip synchronously inside the .print click handler instead, while the user gesture is still active, so the browser allows the window.open() through. The form is then submitted as before to confirm the hold. The reserve_id is taken from the hidden input already present in the modal form; hold-transfer-slip.pl needs only the reserve_id and does not require the hold to have been moved to "Waiting" state first, so the slip content is correct.
To test: 1. Set syspref HoldsAutoFill = "Don't". 2. Place a hold for a patron whose pickup branch is different from your logged-in branch. 3. Check in the item at your logged-in branch. 4. The "Hold found" modal appears. 5. Click "Print slip, transfer, and confirm". 6. Confirm the hold transfer slip opens in a new window and is not blocked by the browser's popup blocker. 7. Confirm the hold is still correctly confirmed and the item placed in transit. 8. Repeat with HoldsAutoFill = "Don't" and a same-branch hold, clicking "Print slip and confirm" instead, and confirm the slip opens for that path too.
Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk>
In step 1 the test plan is set HoldsAutoFill = "Don't". In step 8 it is Repeat with HoldsAutoFill = "Don't". Can you clarify the test plan here? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Re QA question about the test plan (step 1 vs step 8 both setting HoldsAutoFill = "Don't"): This is intentional, not a copy/paste error. HoldsAutoFill controls whether the "Hold found" modal (which contains the "Print slip..." button this patch fixes) appears at all: - If HoldsAutoFill = "Do", the hold is auto-filled/transferred silently and the modal never appears, so the patched code path isn't exercised at all. - So HoldsAutoFill must stay "Don't" for both steps 1-7 and step 8 - there's no second syspref value being tested here. What differs between the two is the *hold scenario*, not the syspref: - Steps 2-7: pickup branch differs from the checkin branch -> "transfertodo" is true -> modal shows "Print slip, transfer, and confirm" - Step 8: pickup branch is the *same* as the checkin branch -> "transfertodo" is false -> modal shows "Print slip and confirm" instead Both buttons share the same click handler this patch touches (returns.tt), so step 8 is there to cover that second button/scenario, not a different HoldsAutoFill value. Happy to reword the commit's test plan if that would help future QA - let me know. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42505 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org