Bug: Second tab does not mirror active scan state and in-progress indicators

[techmore]

Title: Second tab does not mirror active scan state and in-progress indicators

Type: bug
Severity: high
Area: multi-tab realtime UI / scan runtime / Socket.IO state sync

Description:
When two tabs are open and a scan is started in one tab, the second tab does not consistently show the same in-progress state. Live text/log updates may appear, but the secondary tab can miss key scan-state UI such as the active button pulse and the same ongoing scan context shown in the primary tab.

Expected Behavior:
Any already-open tab should reflect the same active scan state in real time, including:

• active scan button pulse
• in-progress status/timer context
• matching scan feedback indicating a scan is currently running

Actual Behavior:
The second tab can lag or drift from the initiating tab, especially around visual state that indicates a scan is still active.

Steps to Reproduce:

1. Open tab 1 and tab 2 against the same local UI.
2. Start a scan from tab 1.
3. Observe tab 2 while the scan is running.

Evidence:

• Recent user reports show live feedback appearing in tab 2 without the same active scan indication.
• Relevant code paths:
  • /Users/techmore/projects/NmapUI/nmapui/jobs.py
  • /Users/techmore/projects/NmapUI/nmapui/app_bindings.py
  • /Users/techmore/projects/NmapUI/nmapui/handlers/connections.py
  • /Users/techmore/projects/NmapUI/static/js/scan_runtime.js
  • /Users/techmore/projects/NmapUI/static/js/report_generation_ui.js

Proposed Fix:
Make active scan state a single shared runtime source for all open tabs and ensure the UI derives pulsing/in-progress indicators from that shared state without tab-local drift.

Implementation Notes:

• Verify existing-tab fanout, not just late-join replay
• Verify job_status and feedback-driven UI state cannot overwrite each other incorrectly
• Add browser-level regression coverage that asserts both tabs show the same active scan indicator while the scan is running

Related Issues:

• Bug: Existing open tabs do not receive live scan updates when another tab starts a scan #127
• Bug: Existing tabs receive idle job_status instead of owner job state during active multi-tab scans #128

[techmore]

Additional reproduction detail from current testing:

Observed behavior:

• With a second tab already open, it briefly shows synchronized in-progress scan information for a couple of seconds.
• During that window, the active scan button still does not pulse in the second tab.
• Then the synchronized scan console/UI data disappears from the second tab.
• After that, the Complete + PDF button starts pulsing instead, even though the active operation is the scan started from the other tab.

Implication:
This looks less like a total multi-tab delivery failure and more like a frontend state transition bug where:

1. the second tab initially receives some correct active-scan state,
2. that state is later overwritten or cleared,
3. the wrong job visual state is then inferred and applied (report pulse instead of scan).

Likely areas to inspect:

• /Users/techmore/projects/NmapUI/static/js/scan_runtime.js
• /Users/techmore/projects/NmapUI/static/js/report_generation_ui.js
• /Users/techmore/projects/NmapUI/static/js/discovery_ui.js
• cross-talk between scan_feedback, job_status, and report-state fallback logic

This should be treated as a regression in client-side state reconciliation across tabs.

[techmore]

Implemented another fix on codex/sqlite-lock-hardening for the shared feedback-container race.\n\nWhat changed:\n- static/js/report_generation_ui.js: report timer teardown no longer clears the shared feedback container; it now only hides the timer and cancels stale hide timers before a new report timer starts\n- this prevents an old idle/report reset from wiping live scan/report text a few seconds later in another tab\n- tests/test_runtime_contract.py: pinned the new report UI contract so the shared container is not cleared again\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_runtime_contract.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 279 passed, 6 skipped\n\nThis specifically targets the refined repro where tab 2 briefly showed synced activity and then lost the feedback text a few seconds later.

[techmore]

Added browser-regression coverage for the stricter live multi-tab timing case on codex/sqlite-lock-hardening.\n\nNew coverage:\n- open both tabs first\n- then start an active report state and fan out live job_status + scan_feedback\n- then start an active scan state and fan out live job_status + scan_feedback\n- both tabs must reflect the correct pulsing button and not pulse the wrong one\n\nFiles:\n- tests/test_browser_regressions.py\n- tests/test_runtime_contract.py\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_runtime_contract.py tests/test_browser_regressions.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 280 passed, 8 skipped\n\nThis does not close the bug by itself, but it gives us a direct guardrail for the exact two-open-tabs-first timing window you reported.

[techmore]

Added handler-level integration coverage on codex/sqlite-lock-hardening for two already-connected tabs using the real connection + scan-job handlers.\n\nNew tests prove:\n- start_scan broadcasts running job_status to an existing second tab\n- generate_report broadcasts running job_status to an existing second tab\n- the path uses the actual connection registration, broadcaster, and build_event_helpers(...) fanout\n\nFiles:\n- tests/test_runtime_info_handlers.py\n- tests/test_runtime_contract.py\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_runtime_info_handlers.py tests/test_runtime_contract.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 283 passed, 8 skipped\n\nThis narrows the remaining bug to frontend/browser state reconciliation rather than the basic backend fanout path.

[techmore]

Implemented another frontend-state fix on codex/sqlite-lock-hardening.\n\nWhat changed:\n- static/js/scan_runtime.js: when a scan job enters running/cancelling state, the scan runtime now clears stale report visual state if there is no active report job for that tab\n- this targets the case where a secondary tab carries forward old report pulse/timer state and then misrepresents a new scan as Complete + PDF activity\n- tests/test_runtime_contract.py: pinned the new guard in the scan-runtime module\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_runtime_contract.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 283 passed, 8 skipped

[techmore]

Implemented another frontend-state tightening pass on codex/sqlite-lock-hardening.\n\nWhat changed:\n- static/js/report_generation_ui.js: report visual sync now clears stale scan pulse state when a report becomes active and no scan job is active\n- report feedback fallback now refuses to pulse report UI if either a scan or report job is already marked running/cancelling for that tab\n- static/js/scan_runtime.js: exported syncScanJobVisualState so the report runtime can clear stale scan pulse state explicitly\n- tests/test_runtime_contract.py: pinned the new precedence rules\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_runtime_contract.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 283 passed, 8 skipped\n\nThis specifically targets the remaining case where a secondary tab can pulse the wrong button because stale scan/report visual state survives into the next active job.

[techmore]

Implemented a backend fix for mid-run new-tab hydration on codex/sqlite-lock-hardening.\n\nWhat changed:\n- nmapui/handlers/history.py: get_job_status no longer blindly emits the requesting tab’s own idle state first\n- when a broadcaster reports an active owner for scan or report, the handler now prefers that active owner’s running/cancelling job payload for the requesting tab\n- this prevents a newly opened tab from replaying the correct active job state on connect and then immediately clearing its own pulse with a follow-up idle get_job_status response\n- tests/test_socketio_integration.py: added coverage for the preferred-owner behavior\n\nVerification:\n- ./.venv/bin/python -m pytest -q tests/test_socketio_integration.py tests/test_runtime_contract.py\n- ./.venv/bin/python -m pytest -q\n\nResult: 284 passed, 8 skipped\n\nThis specifically targets the user report that opening a tab after a scan has already started shows some replayed console history but does not keep the scan button pulsing.

[techmore]

Grouping under #161 (Multi-tab scan state consistency). Closing as duplicate to track work in the initiative.

[techmore]

Tracked in #161.