Skip to content

fix(titlebar): keep window controls under modal masks and localize their tooltips - #2744

Open
HandSonic wants to merge 2 commits into
OtterMind:mainfrom
HandSonic:fix/titlebar-modal-stacking
Open

fix(titlebar): keep window controls under modal masks and localize their tooltips#2744
HandSonic wants to merge 2 commits into
OtterMind:mainfrom
HandSonic:fix/titlebar-modal-stacking

Conversation

@HandSonic

Copy link
Copy Markdown
Contributor

Related issue

N/A — two defects found by reviewing the #2711 desktop chrome series; described below.

Summary

  • The app title bar has carried z-index 10001 since the 4.0.0 code drop (splash-era convention) where it hosted no interactive chrome. Since 2771426 it hosts the real Windows window controls, which now render above antd modal masks (z-index 1000): while an unsaved-changes confirmation is open, the close button stays clickable and can quit the whole application, bypassing the guard. Lowered to 999 — the highest value below the modal layer and above every in-flow workspace stacking context; dropdown menus opened from the bar portal to body and styles/global.ts already forces .ant-dropdown to z-index 11000, so menu behavior is unchanged.
  • The minimize/maximize/restore/close buttons hardcoded English aria-label/title strings while the rest of the bar is localized. They now use common.window.{minimize,maximize,restore,close}, added to every maintained locale (en-US, zh-CN, ja-JP, ko-KR, es-ES); i18n source hashes refreshed via validate-i18n.cjs --write-source-hashes (same method as dd27eb2) plus a new key-parity test wired as test:i18n-window-controls.

Affected surfaces

  • Frontend / Web
  • Backend / API / Storage
  • Database plugin / Driver
  • JCEF / Desktop packaging
  • CI / Build / Release
  • Documentation only

Verification

Risk and compatibility

  • Public API or stored data: N/A.
  • Database or driver compatibility: N/A.
  • Network, privacy, or security: N/A.
  • Community / Local / Pro boundary: N/A.
  • Backward compatibility: purely visual stacking + tooltip text.

Reviewer map

  • Start here: AppTitleBar/style.ts (z-index + comment), AppTitleBar/index.tsx (i18n keys), src/i18n/*/common.ts.
  • Failure condition: any future in-flow element above z-index 999 would need the constant revisited.
  • Rollback or disable path: revert the two commits independently.

Contributor declaration

  • I linked the Issue that defines this change.
  • I tested the affected behavior and reported the actual results above.
  • I did not include credentials, private data, or generated build output.
  • I disclosed substantial AI assistance below, or this PR contains no substantial AI-generated code.

AI assistance: substantial — fixes and tests drafted with AI assistance, verified locally and cross-checked by a second pass.

The app title bar has carried z-index: 10001 since the initial 4.0.0
code drop (d404467), where it only needed to outrank the host splash
overlay convention (OpenScreenAnimation z-index 10000, removed early in
init) while the bar hosted no interactive chrome. Since 2771426 the
bar hosts real window controls (minimize/maximize/close via jcefApi),
and antd modal masks/wraps plus the custom DraggableResizableModal
overlay render at z-index 1000, so on the Windows desktop build the
window close button floated above every confirmation dialog and could
close the app while an unsaved-changes guard modal was open.

Lower the bar to z-index 999: the highest value still below the modal
layer (1000), and above every in-flow workspace stacking context (max
z-index inside content is 100). Dropdown menus opened from the bar
(CommunityAppMenu) are unaffected because they portal to document.body
and global.ts already forces .ant-dropdown to z-index 11000. The
-webkit-app-region drag area is not influenced by z-index.
The Windows window control buttons (minimize/maximize/restore/close)
hardcoded English aria-label/title strings while the rest of the title
bar (CommunityAppMenu) already uses i18n('common.menu.*').

Add common.window.{minimize,maximize,restore,close} to every maintained
locale (en-US, zh-CN, ja-JP, ko-KR, es-ES) and use them for both the
aria-label and title of the three window control buttons. Refresh the
English source hashes in scripts/i18n-source-hashes.json via
'node ./scripts/validate-i18n.cjs --write-source-hashes' (same method as
dd27eb2) and add a key-parity test (yarn test:i18n-window-controls)
asserting the four keys exist non-empty in every locale.
@HandSonic
HandSonic requested review from a team and openai0229 as code owners August 23, 2026 18:54
@openai0229 openai0229 moved this to In Review in Chat2DB Community Aug 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

2 participants