"Upload and print" still shows the confirmation modal — it should print without one (the modal is Upload-only) #81

New Issue

walterioo · 2026-07-02T05:21:58Z

walterioo commented

2026-07-02 05:21:58 +00:00

Description

When you use Upload and print in OrcaSlicer, the bridge pops up the print-start confirmation modal even though it's also starting the print. The modal makes it look like you still need to confirm the AMS/Spoolman slot mapping, but the printer has already started — so the modal is spurious there. That modal really belongs to plain Upload, where it lets you review/assign slots and then start.

Steps to Reproduce

In OrcaSlicer, hit Upload and print (e.g. with "switch to Device tab after upload" turned on).
The bridge shows the print-start modal — and the printer is already printing.

Expected Behavior

Upload (upload-only): show the confirmation modal and wait — the print starts only when you confirm (this is where reviewing/assigning slots makes sense).
Upload and print: the print command already comes from OrcaSlicer, so there's nothing to confirm — it should just start the print, with no modal.

Actual Behavior

With Upload and print, the modal shows up and the print starts anyway — so the modal is misleading and redundant.

Notes

In handle_file_upload, the auto-print path (print=true) already clears file_ready, so in principle the modal shouldn't open on its own — but it still does. The fix should make sure the confirmation modal never opens when print=true; it should only open for upload-only.

Environment

KX-Bridge Version: nightly (a16062f)
OrcaSlicer Version: 2.4.1-KX1
Moonraker/Klipper Version: bridge-emulated (v0.9.3-1)
Operating System: Ubuntu 24.04 (Docker)
Installation: Docker

## Description When you use **Upload and print** in OrcaSlicer, the bridge pops up the print-start confirmation modal even though it's also starting the print. The modal makes it look like you still need to confirm the AMS/Spoolman slot mapping, but the printer has already started — so the modal is spurious there. That modal really belongs to plain **Upload**, where it lets you review/assign slots and then start. ## Steps to Reproduce 1. In OrcaSlicer, hit **Upload and print** (e.g. with "switch to Device tab after upload" turned on). 2. The bridge shows the print-start modal — and the printer is already printing. ## Expected Behavior - **Upload** (upload-only): show the confirmation modal and wait — the print starts only when you confirm (this is where reviewing/assigning slots makes sense). - **Upload and print**: the print command already comes from OrcaSlicer, so there's nothing to confirm — it should just start the print, with **no modal**. ## Actual Behavior With **Upload and print**, the modal shows up *and* the print starts anyway — so the modal is misleading and redundant. ## Notes In `handle_file_upload`, the auto-print path (`print=true`) already clears `file_ready`, so in principle the modal shouldn't open on its own — but it still does. The fix should make sure the confirmation modal never opens when `print=true`; it should only open for upload-only. ## Environment - KX-Bridge Version: nightly (`a16062f`) - OrcaSlicer Version: 2.4.1-KX1 - Moonraker/Klipper Version: bridge-emulated (v0.9.3-1) - Operating System: Ubuntu 24.04 (Docker) - Installation: Docker

walterioo changed title from ~~"Upload and print" starts the print immediately, ignoring the print-start confirmation dialog~~ to "Upload and print" still shows the confirmation modal — it should print without one (the modal is Upload-only)

2026-07-02 05:31:55 +00:00

viewit commented

2026-07-02 19:33:50 +00:00

Thanks for the detailed report. Looking at the code:

In handle_file_upload, when print=true the bridge sets file_ready = "" (empty) before starting the print, so the frontend poll should never see a non-empty file_ready during an auto-print.
The frontend only opens the modal when s.file_ready && s.print_state === "standby" — if file_ready is empty, no modal.

I cannot reproduce this locally. Could you check the browser console (F12) at the moment the modal appears and tell me:

What does s.file_ready show in the poll response at that moment? (Network tab → /api/state response)

This looks like it could be a timing issue specific to your setup (network latency between OrcaSlicer and the bridge, or a fast poll tick catching a transitional state).

Thanks for the detailed report. Looking at the code: - In `handle_file_upload`, when `print=true` the bridge sets `file_ready = ""` (empty) *before* starting the print, so the frontend poll should never see a non-empty `file_ready` during an auto-print. - The frontend only opens the modal when `s.file_ready && s.print_state === "standby"` — if `file_ready` is empty, no modal. I cannot reproduce this locally. Could you check the browser console (F12) at the moment the modal appears and tell me: 1. What does `s.file_ready` show in the poll response at that moment? (Network tab → `/api/state` response) This looks like it could be a timing issue specific to your setup (network latency between OrcaSlicer and the bridge, or a fast poll tick catching a transitional state).

walterioo commented

2026-07-03 18:46:53 +00:00

After a long debug session, found out it was a missconfig on my part. Closing the issue

👍 1

walterioo closed this issue

2026-07-03 18:46:53 +00:00

Sign in to join this conversation.