Fix floating bar visibility issues with queued notifications

[eulicesl]

Summary

Fixes #6972 — with "Show floating bar" turned off, the floating bar reappears during normal use and then stays on screen permanently.

Root cause

When the bar is disabled, floating-bar notifications (proactive assistants, trial banner) still surface it temporarily by design: presentNotification sets notificationWasTemporarilyShown = true, and dismissNotificationAndAdvanceQueue re-hides the bar when the notification goes away.

That flag was clobbered mid-chain: when a queued notification is presented (any notification arriving during another's 6-second display window queues), the window is already visible from the temp-show, so the else branch reset notificationWasTemporarilyShown = false. When the last notification in the chain dismissed, the re-hide condition was false — and the bar stayed visible forever despite the toggle being off.

This matches the report exactly ("continue using the application for a period of time… the bar just appears forever after a moment"): proactive assistants regularly emit notification bursts (e.g. focus-lost/regained), so two notifications chaining is a routine occurrence. The sibling path showTemporarily() was already patched for this same symptom; the notification-queue path was missed.

Fix

Preserve the flag for the duration of the notification chain — it now means "the bar was hidden when this chain started". It is still consumed by the re-hide or reset when the chain ends, so all other lifecycle paths are unchanged:

• Bar enabled, notification arrives → flag stays false, no behavior change.
• Bar disabled, single notification → temp-show, re-hide after dismiss (unchanged).
• Bar disabled, queued notifications → temp-show survives the chain, bar now re-hides after the last dismiss (the bug).
• User clicks a notification into a chat → conversation-close path already re-hides when !isEnabled.
• User re-enables the bar mid-chain → isEnabled is rechecked at chain end, bar correctly stays up.

Follow-up (review feedback): a notification queued during an active AI conversation is flushed by closeAIConversation's completion while the window is still visible, so the temp-show flag was never armed and the unconditional orderOut(nil) hid the just-presented notification instantly. Two complementary changes: presenting a notification while the bar is disabled now always arms notificationWasTemporarilyShown (even if the window is visible), and the close path skips orderOut when a flushed notification is on screen — its dismissal re-hides the bar instead.

Also appends the user-facing entry to unreleased in desktop/CHANGELOG.json.

Testing

• Traced every producer/consumer of notificationWasTemporarilyShown and the show/hide lifecycle paths (show, hide, showTemporarily, openAIInput*, snooze, conversation close) — details above.
• Authored from a Linux environment, so no local macOS build; the changes are control-flow-only edits in two methods of one class (no signature/type changes). Codemagic's clean release build covers compilation.
• Suggested manual verification on macOS: disable "Show floating bar", trigger two floating-bar notifications within ~6s of each other (or use the proactive assistant focus sounds), and confirm the bar hides again after the second notification dismisses.

[Copilot]

Pull request overview

Fixes an edge case where the floating control bar could remain permanently visible even when the user has disabled “Show floating bar”, due to queued notification presentation/reset logic and an AI-conversation-close interaction that could hide a just-flushed notification.

Changes:

• Preserve notificationWasTemporarilyShown across a queued-notification chain so the bar is re-hidden after the final notification dismisses when the bar is disabled.
• Prevent closeAIConversation() from immediately hiding the window when a queued notification was just flushed and is currently being shown.
• Add an unreleased changelog entry for the user-facing fix.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
desktop/Desktop/Sources/FloatingControlBar/FloatingControlBarWindow.swift	Fixes notification-chain flag handling and avoids swallowing flushed notifications on AI conversation close.
desktop/CHANGELOG.json	Documents the fix in the unreleased section.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[greptile-apps]

Greptile Summary

Fixes a floating-bar visibility regression (#6972) where the bar would stay permanently on-screen when "Show floating bar" is off and two notifications arrive within the same 6-second display window. The root cause was that presentNotification was resetting notificationWasTemporarilyShown to false whenever the window was already visible (queued notification path), so the re-hide at chain-end never fired.

• presentNotification: Removes the explicit else { notificationWasTemporarilyShown = false } reset, and additionally arms the flag whenever the bar is disabled (even if the window is already visible), covering the case where a queued notification is flushed right as an AI conversation closes.
• closeAIConversation async block: Guards the orderOut(nil) with && currentNotification == nil so that a notification flushed by flushQueuedNotificationsIfPossible() in the same block isn't immediately hidden; the notification's own dismissal path re-hides the bar instead.

Confidence Score: 4/5

The change is a focused two-site control-flow fix inside a single class; no interface or data-model changes. The flag lifecycle is traced correctly through every chain path.

Both edits are narrow and self-contained. The removal of the explicit else { notificationWasTemporarilyShown = false } reset is the most structurally significant change: it now relies on the flag already being false when a notification arrives with the bar enabled and the window visible, rather than actively clearing it. This is safe given that dismissNotificationAndAdvanceQueue always resets the flag at chain-end, but it leaves a subtle stale-true window if a chain is ever abandoned without going through that path (e.g. snooze). In all traced paths the snooze orderOut causes the next notification to see !window.isVisible, re-arming the flag correctly, so no concrete failure scenario exists. No macOS build verification by the author is the only other note; Codemagic covers compilation.

desktop/Desktop/Sources/FloatingControlBar/FloatingControlBarWindow.swift — specifically the interaction between snooze/unsnooze and the now-implicit flag-reset assumption.

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/FloatingControlBar/FloatingControlBarWindow.swift	Two targeted control-flow fixes to presentNotification and the closeAIConversation async completion block; the flag semantics are well-analysed and all chain paths traced correctly.
desktop/CHANGELOG.json	Appends a user-facing bug-fix entry to the unreleased array; no logic changes.

Sequence Diagram

sequenceDiagram
    participant N as Notification Emitter
    participant M as FloatingControlBarManager
    participant W as FloatingControlBarWindow

    Note over M: isEnabled = false
    N->>M: enqueueNotification(A)
    M->>M: presentNotification(A)
    Note over M: !window.isVisible → arm flag, orderFrontRegardless
    M->>W: showNotification(A)

    N->>M: enqueueNotification(B) [within 6s]
    M->>M: window has currentNotification → pendingNotifications.append(B)

    Note over M: 6s timer fires
    M->>M: dismissNotificationAndAdvanceQueue()
    M->>W: dismissNotification()
    M->>M: pendingNotifications not empty → presentNotification(B)
    Note over M: (NEW) !isEnabled → keep flag true, skip orderFrontRegardless
    M->>W: showNotification(B)

    Note over M: 6s timer fires
    M->>M: dismissNotificationAndAdvanceQueue()
    M->>W: dismissNotification()
    Note over M: pendingNotifications empty
    Note over M: (NEW) flag still true → orderOut ✓
    M->>W: orderOut(nil)
    M->>M: "notificationWasTemporarilyShown = false"

Loading

_{Reviews (1): Last reviewed commit: "fix(desktop): cover notifications flushe..." | Re-trigger Greptile}