fix(quick-search): Esc from the tray now closes AND returns to the tray
Two bugs in the same flow, both on the tray-originated path. 1. Esc did nothing until the search box was clicked: after the tray restore the WebView2 child does not hold the OS keyboard focus, so no keystroke reached the page at all — a DOM .focus() cannot fix that. Both quick-search entry points now call WebBrowser.SetFocus after restoring. 2. Esc closed the modal but left the app on screen. In fill mode closeQuickSearchModal fires cancelAutofill and then minimizeToTray, and two back-to-back window.location.href assignments COALESCE — the minimise was dropped. The copy path was unaffected because it never calls cancelAutofill, which is why this only showed up here. Deferred by a setTimeout(0), the same remedy CLAUDE.md already documents for quickunlock/store + pin/clear. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
+6
-1
@@ -502,7 +502,12 @@ function closeQuickSearchModal(keepClipboard) {
|
||||
if (quickSearchHideAfter) {
|
||||
quickSearchHideAfter = false;
|
||||
if (Bridge.active && typeof Bridge.minimizeToTray === 'function')
|
||||
Bridge.minimizeToTray(!!keepClipboard);
|
||||
// Deferred: in fill mode the cancelAutofill above already fired a
|
||||
// cmd:// navigation, and two back-to-back window.location.href
|
||||
// assignments COALESCE — only one survives, so the minimise was
|
||||
// silently dropped and the app stayed on screen. Same pitfall as
|
||||
// the quickunlock/store + pin/clear pair in doChangeMasterPassword.
|
||||
setTimeout(() => Bridge.minimizeToTray(!!keepClipboard), 0);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user