GeezerVison

Walkthrough

This pull request introduces master-password-protected note locking, real-time Firebase SSE synchronization, automatic window attachment system to show/hide notes based on foreground process or folder context, enhanced window position/size persistence, and localization updates. The installer version is bumped to 0.2.0.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant MainWindow
    participant WindowAttachmentService
    participant NoteWindow
    participant AppSettings

    User->>MainWindow: Set note to attach to process
    MainWindow->>NoteWindow: Store AttachTarget, AttachMode
    NoteWindow->>AppSettings: Save position & attachment config
    
    loop Continuous Monitoring
        WindowAttachmentService->>WindowAttachmentService: Poll foreground window
        alt Foreground matches AttachTarget
            WindowAttachmentService->>MainWindow: ShowRequested event
            MainWindow->>NoteWindow: Show & position near target
        else No match & threshold reached
            WindowAttachmentService->>MainWindow: HideRequested event
            MainWindow->>NoteWindow: Hide note
        end
    end
    
    User->>NoteWindow: Detach from process
    NoteWindow->>NoteWindow: Clear AttachTarget/Mode
    NoteWindow->>AppSettings: Save updated attachment state
    NoteWindow->>MainWindow: Fire AttachmentChanged event

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~75 minutes

Possibly related PRs

• feat: AI integration, custom prompts, global hotkeys, reminder UI #2: Modifies ActionPanel.CreateSettings(...) signature with optional callbacks, introducing similar settings sub-panel extension patterns.
• feat: persist window state across sessions, migrate to .NET 10, and make CUDA backend configurable #3: Overlaps on window position/size persistence and WindowHelper resize behavior for main/note windows.
• feat: fonts, note styles, Groq voice & Firebase sync #4: Touches AppSettings sync-related APIs and ActionPanel settings extensibility that align with this PR's settings changes.

Poem

🐰 A rabbit bounds through windows with glee,
SSE streams real-time, notes locked securely!
Attachments track processes, positions persist—
Where windows are foreground, small notes shan't be missed! 🔐✨

• X
• Mastodon
• Reddit
• LinkedIn

• **Note locking & password protection** — secure individual notes with master password; locked
  notes show obfuscated preview and require password to open/delete
• **Firebase real-time synchronization** — replaced 45-second polling with SSE streaming listener
  for instant bidirectional sync and live refresh of note windows
• **Window attachment** — attach note windows to running processes, browser tabs, and Explorer
  folders with auto-show/hide behavior based on foreground window
• **Timezone-safe conflict resolution** — implemented merge logic using UTC comparisons matching web
  client behavior, with deletion tombstone tracking
• **Window resizing** — made all windows resizable with visual grips, persist window positions and
  sizes across sessions
• **Enhanced UI** — added sync button to main window title bar, relocated settings button to status
  bar, added lock and attachment indicators to note windows
• **Localization** — added 32+ new localization keys for security, attachment, and sync features in
  English and French
• **Bug fix** — corrected drag bar z-order in notepad window to prevent blocking title bar
  interactions

Firebase real-time sync, window attachment, and note locking

• Added WindowAttachmentService integration for attaching notes to running processes, browser
 tabs, and Explorer folders with auto-show/hide behavior
• Implemented Firebase real-time SSE listener (StartFirebaseListener, StopFirebaseListener)
 replacing 45-second polling with instant refresh
• Added note locking with master password support; locked notes show obfuscated preview and require
 password to open/delete
• Enhanced window resizing: made windows resizable, added resize grips, and persist window
 positions/sizes for main window and individual notes
• Added attachment UI in note context menu with process picker, web tab picker, and folder picker
• Improved compact mode to preserve pre-compact dimensions and animate width changes

MainWindow.xaml.cs

New service for window attachment and auto-visibility

• New service that monitors foreground windows and Explorer folders to auto-show/hide attached notes
• Implements Win32 event hooks (SetWinEventHook) for foreground window changes and timers for
 Explorer folder polling
• Supports three attachment modes: process (running application), title (browser tab by window
 title), and folder (Explorer path)
• Provides helper methods to get visible windows, web tabs, and open Explorer paths with active tab
 detection
• Calculates and saves relative note position offsets to target windows for consistent placement

WindowAttachmentService.cs

Note locking, attachment UI, and sync reload support

• Added lock button and attachment icon to note title bar with visual indicators
• Implemented ReloadAfterSync() to update note content when remote changes arrive via Firebase
• Added attachment menu with process, web tab, and folder picker options
• Enhanced compact mode to preserve pre-compact width/height and animate width during state
 transitions
• Improved text color handling for full-color note style to maintain readability on pastel
 backgrounds
• Added SetPinnedOnTop() method and lock toggle handler with password creation/verification

NoteWindow.xaml.cs

Description

The new lock feature only gates UI access; locked note Content is still serialized to notes.json and
pushed to Firebase/WebDAV in plaintext, so “password protection” does not protect confidentiality.
Anyone with local file access or sync/RTDB access can read locked note content directly.

Code

NotesManager.cs[R49-52]

+    public void Save(bool localOnly = false)
    {
        try
        {

Evidence

Notes are persisted and synced by serializing the full NoteEntry list (including Content) regardless
of IsLocked. The PR introduces IsLocked but does not add any encryption layer before writing
notes.json or pushing to cloud.

NotesManager.cs[49-66]
NotesManager.cs[480-503]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Locked notes are not actually protected: `NoteEntry.Content` is written and synced in plaintext even when `IsLocked=true`.

## Issue Context
Current implementation adds `IsLocked` and password prompts, but storage/sync paths still serialize the entire note model unchanged.

## Fix Focus Areas
- NotesManager.cs[49-66]
- NotesManager.cs[453-503]

## Implementation notes
- Encrypt `Content` (and any other sensitive fields) when `IsLocked=true` before persisting/syncing.
- Store encryption metadata per note (e.g., version, salt, nonce/IV) and decrypt only after successful password entry.
- Use a slow KDF (e.g., PBKDF2) to derive a key from the master password; avoid raw SHA-256 as a key/verification primitive.
- Ensure Firebase/WebDAV payloads never include plaintext for locked notes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The master password hash is uploaded to Firebase settings and later restored, enabling offline
brute-force if RTDB is accessed and making local DPAPI protection irrelevant. A local “reset
password” can also be undone by the next settings pull (rehydrating the remote hash).

Code

NotesManager.cs[R185-193]

            ["theme"] = AppSettings.LoadThemeSetting(),
            ["backdrop"] = AppSettings.LoadSettings().Type,
        };
+        var masterPwHash = AppSettings.LoadMasterPasswordHash();
+        if (!string.IsNullOrEmpty(masterPwHash))
+            settings["masterPasswordHash"] = masterPwHash;
        await Firebase.PushSettingsAsync(settings);
    }

Evidence

SyncSettingsToFirebase includes masterPasswordHash in the uploaded settings, and
SyncSettingsFromFirebase writes any remote value back locally via DPAPI. This explicitly moves the
hash to cloud storage.

NotesManager.cs[178-222]
AppSettings.cs[38-78]
NotesManager.cs[149-163]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The master password hash is synced to Firebase, enabling offline brute force and negating local DPAPI protection.

## Issue Context
`SyncSettingsToFirebase` uploads `masterPasswordHash`, and `SyncSettingsFromFirebase` restores it on startup.

## Fix Focus Areas
- NotesManager.cs[178-222]
- NotesManager.cs[149-163]

## Implementation notes
- Remove `masterPasswordHash` from settings sync entirely (keep it local-only).
- If cross-device unlock is required, store only an encrypted key-wrapping artifact (e.g., a random key encrypted with a password-derived key) rather than a reusable verifier/hash.
- Ensure reset password cannot be reverted by remote settings pulls.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Reset-confirm flow accepts any non-empty password when LoadMasterPasswordHash() returns null
(missing/corrupt/DPAPI failure), because the mismatch check is skipped. This allows deleting the
local master password without actually verifying it in those cases.

Code

ActionPanel.cs[R790-804]

+            if (requirePassword && passwordBox != null && errorText != null)
+            {
+                if (string.IsNullOrEmpty(passwordBox.Password))
+                {
+                    errorText.Text = Lang.T("password_required");
+                    errorText.Visibility = Visibility.Visible;
+                    return;
+                }
+                var storedHash = AppSettings.LoadMasterPasswordHash();
+                if (storedHash != null && AppSettings.HashPassword(passwordBox.Password) != storedHash)
+                {
+                    errorText.Text = Lang.T("wrong_password");
+                    errorText.Visibility = Visibility.Visible;
+                    return;
+                }

Evidence

The confirm handler checks for mismatch only when storedHash != null; LoadMasterPasswordHash()
returns null on exceptions or missing file, causing the verification branch to be skipped.

ActionPanel.cs[788-807]
AppSettings.cs[56-66]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Password verification for reset is bypassed when the stored hash cannot be loaded.

## Issue Context
`storedHash != null` gates the mismatch check; null means no verification occurs.

## Fix Focus Areas
- ActionPanel.cs[788-807]
- AppSettings.cs[56-66]

## Implementation notes
- If `requirePassword` and `storedHash` is null/empty, show an error and block the reset (or require an alternate stronger confirmation flow).
- Consider loading the hash at click-time and treating load failures as hard failures for destructive actions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Window attachment tracking uses _visibleNoteIds, but hide logic only iterates notes that currently
have AttachMode set; if a note is detached (AttachMode cleared) or removed, its id can remain
visible and HideRequested will never fire. This can leave attached note windows stuck visible
after detaching/deleting.

Code

WindowAttachmentService.cs[R130-165]

+    private void EvaluateProcessAttachments(string? foregroundProcess, IntPtr hwnd)
+    {
+        var processNotes = _notes.Notes
+            .Where(n => n.AttachMode == "process" && !string.IsNullOrEmpty(n.AttachTarget))
+            .ToList();
+
+        var isOwnProcessForeground = IsOwnProcessForeground(foregroundProcess);
+
+        foreach (var note in processNotes)
+        {
+            var matches = IsSameProcessTarget(note.AttachTarget, foregroundProcess);
+
+            if (matches && !IsIconic(hwnd))
+            {
+                MarkAttachmentMatch(note.Id);
+                if (_visibleNoteIds.Add(note.Id))
+                    ShowRequested?.Invoke(note, hwnd);
+            }
+            else if (isOwnProcessForeground && _visibleNoteIds.Contains(note.Id))
+            {
+                // Keep already-attached note visible while user interacts with it
+                // (drag/edit focuses NoteUI, not the target process),
+                // but only while the target window is still actually visible.
+                if (HasAnyVisibleWindowForProcess(note.AttachTarget))
+                {
+                    MarkAttachmentMatch(note.Id);
+                    continue;
+                }
+            }
+
+            if (ShouldHideAfterMiss(note.Id) && _visibleNoteIds.Remove(note.Id))
+            {
+                ClearAttachmentState(note.Id);
+                HideRequested?.Invoke(note.Id);
+            }
+        }

Evidence

EvaluateProcessAttachments/EvaluateWindowTitleAttachments iterate only notes where AttachMode is
'process'/'title', so detached notes are excluded from evaluation and can’t be removed from
_visibleNoteIds. Refresh() just re-runs these checks and doesn’t reconcile _visibleNoteIds
against current note attachment state.

WindowAttachmentService.cs[120-165]
WindowAttachmentService.cs[71-76]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Detached/deleted notes can remain in `_visibleNoteIds` and never get hidden.

## Issue Context
Hide logic only runs for notes still matching attachment filters.

## Fix Focus Areas
- WindowAttachmentService.cs[71-76]
- WindowAttachmentService.cs[130-165]
- WindowAttachmentService.cs[201-236]
- WindowAttachmentService.cs[390-433]

## Implementation notes
- Before evaluating attachments, reconcile `_visibleNoteIds` with current notes/attachment state:
 - Remove ids that no longer exist.
 - Remove ids whose note no longer has an attachment mode/target.
 - Fire `HideRequested` for any removed-visible ids.
- Alternatively, iterate over `_visibleNoteIds` and validate each id against current note state each tick.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

GetOpenExplorerPaths creates COM objects via dynamic (Shell.Application, ShellWindows, window items)
without deterministic release; called every 1.5s, this can accumulate COM references and degrade
memory/performance over long runtimes. Relying on GC for COM cleanup is non-deterministic.

Code

WindowAttachmentService.cs[R499-528]

+            var shellType = Type.GetTypeFromProgID("Shell.Application");
+            if (shellType == null) return [];
+            dynamic shell = Activator.CreateInstance(shellType)!;
+            dynamic windows = shell.Windows();
+            int count = windows.Count;
+            for (int i = 0; i < count; i++)
+            {
+                try
+                {
+                    dynamic w = windows.Item(i);
+                    string? fullName = w.FullName;
+                    if (fullName == null || !fullName.EndsWith("explorer.exe", StringComparison.OrdinalIgnoreCase))
+                        continue;
+                    string? url = w.LocationURL;
+                    if (string.IsNullOrEmpty(url)) continue;
+                    var uri = new Uri(url);
+                    if (!uri.IsFile) continue;
+
+                    var hwnd = (IntPtr)(long)w.HWND;
+                    string locationName = "";
+                    try { locationName = w.LocationName ?? ""; } catch { }
+
+                    var localPath = NormalizePath(uri.LocalPath);
+                    if (string.IsNullOrWhiteSpace(localPath)) continue;
+
+                    allShellWindows.Add((localPath, hwnd, locationName));
+                }
+                catch { }
+            }
+        }

Evidence

The method constructs COM objects with Activator.CreateInstance and iterates windows.Item(i) but
never calls Marshal.ReleaseComObject/FinalReleaseComObject. The service polls this on a timer,
so cleanup timing depends on GC rather than being deterministic.

WindowAttachmentService.cs[493-529]
WindowAttachmentService.cs[35-40]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
COM objects created in `GetOpenExplorerPaths` are not explicitly released.

## Issue Context
Method runs frequently via `_explorerTimer`, so COM references can accumulate.

## Fix Focus Areas
- WindowAttachmentService.cs[493-529]

## Implementation notes
- Use `Marshal.ReleaseComObject` / `Marshal.FinalReleaseComObject` in `finally` blocks for:
 - `shell`
 - `windows`
 - each `w = windows.Item(i)`
- Prefer strongly-typed COM interop wrappers if available; avoid `dynamic` where possible.
- Ensure exceptions still release any partially created COM objects.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Reset notes closes only windows in _openNoteWindows and deletes notes, but it does not close
windows opened via window attachment (_attachedNoteWindows). This can leave attached note windows
open while their underlying notes have been deleted until some later cleanup happens.

Code

MainWindow.xaml.cs[R1195-1201]

+            onResetNotes: () =>
+            {
+                foreach (var w in _openNoteWindows.ToList())
+                    try { w.Close(); } catch { }
+                _openNoteWindows.Clear();
+                _notes.DeleteAllNotes();
+                RefreshCurrentView();

Evidence

Attached windows are tracked in a separate _attachedNoteWindows dictionary and are created outside
_openNoteWindows. The reset handler only closes and clears _openNoteWindows and does not touch
_attachedNoteWindows.

MainWindow.xaml.cs[33-38]
MainWindow.xaml.cs[967-1028]
MainWindow.xaml.cs[1195-1201]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Resetting notes does not close note windows created by the attachment system.

## Issue Context
Attached note windows are tracked separately from manually opened note windows.

## Fix Focus Areas
- MainWindow.xaml.cs[1195-1201]
- MainWindow.xaml.cs[967-1028]

## Implementation notes
- In `onResetNotes`, iterate `_attachedNoteWindows.Values` and close them, then clear `_attachedNoteWindows` / `_attachedTargetHwnds`.
- Optionally call `_attachmentService?.Refresh()` after clearing notes to ensure service state is consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools