Stop popping a modal for the normal record-privilege wait - #246
Merged
Conversation
Starting the engine was showing a "Zoom Join" error modal for raw_media_start_failed/privilege_requested -- the NORMAL first half of Zoom's record-privilege handshake (canStartRawRecording -> NoPermission, engine asks the host, raw_media_ready follows once granted), not a failure. handle_event() already refused to route this into the join-failure/reconnect machinery; it still set m_last_error and fired the error-callback list, which is what popped the modal. Adds a separate NoticeCallback path (ZoomEngineClient::add_notice_callback/ pending_privilege_notice) instead of a severity flag on the existing error callback, so "never reaches a QMessageBox" holds by construction rather than by every subscriber remembering to check a flag. m_last_error is left untouched. The operator copy and the first-vs-repeat classification live in src/zoom-privilege-notice.h (pure, host-tested in tests/zoom-privilege-notice-test.cpp, three mutations killed). The notice clears on raw_media_ready and on leave, rendered as a CvBanner(Warning) in the dock instead of the modal. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The defect
Starting the engine popped a modal error dialog saying raw recording failed. It isn't a failure — it's the normal first half of Zoom's record-privilege handshake:
canStartRawRecordingreturnsNoPermission(6), the engine requests the privilege, the host grants it, and the operator starts the engine again.Reported by the product owner after a live launch today:
Why it was half-right already
zoom-engine-client.cppalready had special handling for this case, and it correctly refused to route it into the join-failure/reconnect machinery — doing that once flipped a healthy joined session to Failed and gatedstart_engine, resubscription and recovery for the rest of the session.But it still set
m_last_errorand fired every error callback, and the dock ends those inQMessageBox::warning. The logic was right; the presentation was wrong.Scope
macOS is where this case exists. The Windows engine emits
raw_media_start_failedonly fornot_in_meetingandrecording_controller_unavailable— both genuine errors that should keep the modal. Verified rather than assumed.Verification
68/68 (67 baseline + new
CoreVideoPrivilegeNotice), 3/3 mutations against the new pins killed and reverted clean.Not verified against a live meeting with a real host grant — that's the next test.
Also carries the
data/bundling fix from #245 via a merge of main, so a single test build gets both.🤖 Generated with Claude Code