test

Reopening after accidental test close; posting the investigation answer next.

Investigation findings for the Escape-key questions:

Clarification on browser default

Pressing Escape does not blur focused <input> / <textarea> elements in Chrome, Firefox, or Safari by default. That blur-on-Escape behavior is an application convention (common in some desktop apps and accessibility workflows), not a browser built-in. What OneDev does today is still relevant to your request; the framing just isn't "restore browser default."

1. Where Escape is intercepted

Several document-level keydown handlers look for keyCode == 27. The global one is in server-core/.../web/page/base/base.js:

$(document).keydown(function(e) {
    if (e.keyCode == 27) // ESC
        e.preventDefault();
});

It calls preventDefault() on every Escape press (no stopPropagation()). That blocks browser defaults such as exiting fullscreen; it does not itself blur or unblur fields.

Other Escape handlers (also document keydown, typically without stopPropagation()):

None of these call activeElement.blur().

2. What Escape is bound to (not a general "pane toggle")

Escape is used as a dismiss / close key for overlays, not a general pane-visibility toggle:

• Mobile sidebar: Escape removes sidebar-docked (closes the drawer).
• Side info: Escape closes it only in overlay mode (narrow viewport or .hide-side-info). On wide layouts the pinned side-info open/closed state is cookie-driven and is not toggled by Escape.
• Modals / floating panels / tooltips: Escape closes them.

So the behavior you hit while typing is usually "close an open overlay," not "toggle the main side pane."

3. Can Escape be made context-aware (blur first, then dismiss)?

Yes, technically. There is no existing setting to configure this today; it would be a product/code change.

A practical approach:

1. In a central Escape handler (or at the start of each dismiss handler), if document.activeElement is an editable control (input/textarea/select, [contenteditable], CodeMirror, etc.), call blur() and return without dismissing UI.
2. On a later Escape with no editable focus, keep today's dismiss behavior.

Caveats to design carefully:

• Markdown / CodeMirror already use Escape for their own UI (hints, fullscreen, etc.).
• Date pickers, Select2, color pickers already special-case Escape.
• Blurring a dirty leave-confirm field before a modal close could change UX unexpectedly.

4. Existing focus-aware shortcut patterns

Yes. The bundled jQuery Hotkeys plugin (server-core/.../web/asset/hotkeys/jquery.hotkeys.js) skips shortcuts when focus is in input-accepting elements / contenteditable (filterInputAcceptingElements, filterTextInputs, filterContentEditable). Markdown and several pickers use that.

The Escape dismiss handlers above do not use that filter; they listen with raw $(document).on("keydown", ...) and only exclude a few overlay widgets (flatpickr, select2, etc.).

Bottom line

• Escape is intentionally handled by OneDev UI dismiss logic; the global handler also preventDefault()s it.
• It is not currently configurable, and it does not blur focused text fields.
• A two-step "blur editable first, then dismiss overlays" behavior is feasible and could reuse the same focus checks Hotkeys already uses, but it would be a new enhancement (not a setting today).

If this answers your investigation questions, we can close the issue. If you want the two-tier Escape behavior implemented, say so and we can follow up as an improvement/feature request.

Apologies, blur was not the correct use of the terminology, I should have meant "lose focus".

No worries — in the DOM, blur() is exactly the API that makes an element lose focus, so the investigation above still applies under that wording.

If that answers your questions, we can close this. If you'd like the two-tier Escape behavior (lose focus on first Escape, then dismiss overlays on a later Escape) implemented as an enhancement, say so and we can follow up.

I want the two-tier Escape behavior implemented

Thanks — implementing the two-tier Escape behavior is an enhancement beyond the scope of this question. Escalating to @robin for follow-up.

I'll create this as a separate issue, now that I have some context.

Sounds good — closing this question since the investigation is answered. Thanks for opening the enhancement separately.

Created Issue Implement Two-Tier Escape Key Behavior: Remove Focus from Editable Fields First, Then Dismiss Overlays (OD-2881)