Weak-password warning: a real focus-getting dialog, from the settled startup sequence

Ed's follow-up: a status line is too easy to miss for something this important — a
dialog that reliably gets focus is wanted. The earlier dialog wasn't wrong in kind,
only in timing: it fired mid-connect from the crypto path, before the window had
finished showing, so it never got clean foreground focus and NVDA couldn't reach it
(and ForegroundDialog dragged the half-shown window out of the tray).

Fix: show the warning from RunStartupNotices — the SAME proven, post-OnShown,
one-dialog-at-a-time sequence the mic-blocked and Realtek warnings use, which reach
NVDA fine. New MaybeWarnWeakPassword uses ForegroundDialog.Show (fronts even from the
tray, clean focus) and fires only when the profile is actually set to stream (send or
receive on) and its password is genuinely weak. The non-modal status-line reminder
stays as the standing prompt after the dialog is dismissed, and the user-initiated
streaming-tick gate is unchanged. Skipped on --silent/muted launches like its peers.

Gate 71/71 + 7 relay tests.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Ednunp
2026-07-27 11:10:24 +01:00
co-authored by Claude Fable 5
parent 027ba905e7
commit af06929a64
+28
View File
@@ -1666,6 +1666,34 @@ public sealed partial class MainForm : Form
MaybeWarnAboutRealtekAsio();
if (IsDisposed) return;
MaybeWarnMicBlockedOnStartup();
if (IsDisposed) return;
MaybeWarnWeakPassword();
}
/// <summary>Startup warning for a profile whose password is too weak to stream under the 5.6 rule.
/// Runs from the SETTLED post-launch notice sequence — after the window is fully shown and
/// activated, one dialog at a time — NOT from the mid-connect crypto path where an earlier version
/// fired it and left a blind user trapped behind a dialog NVDA couldn't reach (Ed, 2026-07-27).
/// From here <see cref="ForegroundDialog"/> pulls it to the front (even from the tray) with clean
/// focus, exactly like the mic-blocked and Realtek warnings that already work with NVDA. Only fires
/// when the profile is actually set up to stream (send or receive on) — otherwise there's no audio
/// to block and the guided prompt on the first streaming tick is enough. The status line carries a
/// standing reminder after this is dismissed.</summary>
private void MaybeWarnWeakPassword()
{
if (IsDisposed || CuePlayer.GloballyMuted) return; // never on a --silent/automated launch
if (!WeakPasswordBlocksAudio(currentProfilePassword, currentAudioKey is not null)) return;
if (!IsSendEnabled && !IsReceiveEnabled) return; // not trying to stream → nothing blocked yet
var advice = PasswordStrength.Critique(currentProfilePassword) ?? "";
ForegroundDialog.Show(owner => MessageBox.Show(owner,
"The password on this profile — the one that protects your audio — is too easy to guess, so "
+ "from this version RemSound won't stream with it. Until it's changed, the people you "
+ "connect to will hear nothing.\n\n"
+ advice + "\n\n"
+ "To fix it: open the File menu and choose “Change this profile's password”, then set "
+ "the SAME new password on every machine you connect with.",
"RemSound — password too weak to stream",
MessageBoxButtons.OK, MessageBoxIcon.Warning));
}
/// <summary>Startup log-folder housekeeping driven by the Logging-tab preferences. Both steps are