[Bug]: Linux right-click menus ignore even forced Light/Dark appearance #27464

Before submitting

• Searched existing reports. [Bug]: Desktop context menus do not inherit imported VS Code themes #10997 concerns imported/custom palettes; this report isolates failure of even forced Light/Dark. [Bug]: "System" appearance stays light on KDE Plasma Wayland (Electron mis-resolves the color scheme) #19119 concerns incorrectly detecting System appearance, whereas this reproduction reports the requested appearance correctly.
• Included an isolated reproduction, runtime state, and underlying source path.

Area

apps/desktop

Steps to reproduce

1. On Linux, open the T3 Code desktop app and select explicit Dark appearance while the GTK theme is light.
2. Open a native right-click menu, such as a thread action menu or a text editing menu.
3. Compare it with the dark application content, then switch the application to explicit Light and reopen the menu.
4. Repeat with a dark GTK theme: native menu colors can remain dark despite explicit Light in the application.

The reporter confirmed that several right-click menus throughout T3 Code are affected, rather than one isolated menu. The installed client version and individual menu examples were not supplied. The independent runtime reproduction below tests the same native Electron menu mechanism, not a complete T3 client session.

Expected behavior

At minimum, native application context menus follow explicit Light/Dark appearance. This report does not require native menus to inherit arbitrary custom theme palette colors.

Actual behavior and reproduced evidence

A minimal Menu.popup() on Electron 44.10.0, the version pinned by current T3 main, ignores explicit Light/Dark for popup colors on the tested Linux GTK path:

Popup screenshots were inspected and the background sampled inside the popup at (110, 135). All captures used a newly created isolated Xvfb display, not a human desktop. Setting the source before window creation, after page load, and waiting for the dark-mode updated event all retained the light popup in the default GTK case. The GTK override was scoped to the diagnostic process; no desktop settings were changed.

Minimal native probe

Save as menu.cjs, run with Electron 44.10.0 and a separate disposable profile. Close the diagnostic window to exit.

const { app, BrowserWindow, Menu, nativeTheme } = require('electron');
const fs = require('node:fs');
const os = require('node:os');
const path = require('node:path');
app.setPath('userData', fs.mkdtempSync(path.join(os.tmpdir(), 'menu-theme-')));
app.on('window-all-closed', () => app.quit());
app.whenReady().then(async () => {
  const win = new BrowserWindow({ width: 900, height: 600 });
  await win.loadURL('data:text/html,<body>Native popup theme check</body>');
  nativeTheme.themeSource = process.argv.at(-1);
  console.log({
    electron: process.versions.electron,
    source: nativeTheme.themeSource,
    nativeDark: nativeTheme.shouldUseDarkColors,
    rendererDark: await win.webContents.executeJavaScript(
      'matchMedia("(prefers-color-scheme: dark)").matches'
    ),
  });
  Menu.buildFromTemplate([{ label: 'Copy' }, { label: 'Paste' }])
    .popup({ window: win, x: 100, y: 100 });
});

electron menu.cjs light
electron menu.cjs dark
GTK_THEME=Adwaita:dark electron menu.cjs light

Diagnosis and scope

T3 already sends resolved light/dark/system through useTheme.syncDesktopTheme → desktopBridge.setTheme → ElectronTheme.setSource → Electron.nativeTheme.themeSource. Both app action menus and editing/spelling/preview popups ultimately use Electron's native menu implementation. Source checked at 5ef56853ef1854da50bc1909c6c0a32700f2cb13.

The runtime control is consistent with the underlying GTK painting path:

• Electron 44.10.0 theme-source setter updates the UI/web appearance override and contains an outstanding GTK dark-theme integration TODO.
• Electron's Linux UI getter selects the GTK theme for native window widgets.
• Chromium 152 GTK popup painting paints the GTK menu CSS context instead of the supplied color provider. That explains the GTK-controlled popup despite correctly reported application dark state.
• Related upstream report: electron/electron#28887. Its discussion also includes KDE/Wayland reports of the right-click popup ignoring theme source.

A narrow underlying repair belongs in Electron's GTK/native-theme integration, including correct restoration when returning to System. No safe T3 JavaScript-only native-menu color fix was established here. BrowserWindow.darkTheme only changes window decoration hints; globally forcing a named GTK theme is not an appropriate application fix.

Relationship to custom menus

#10997 tracks arbitrary imported palette colors. Its maintainer comment explicitly holds the HTML/native menu choice for a product decision. This report adds a separately reproduced basic appearance failure; it does not treat that discussion as approval to replace native menus, change macOS behavior, or replace filesystem dialogs.

Environment and limitations

Diagnostic host: Debian GNU/Linux 13 x64, isolated Xvfb/X11 display, Electron 44.10.0 / Chromium 152.0.7977.169. The reporter confirmed multiple menus throughout the Linux client are affected; the exact desktop session, client version, and individual menu examples remain unconfirmed. Full T3 interaction and Wayland were not exercised; the Electron/GTK reproduction and T3 source path were checked independently. No production app files or user theme configuration were changed.

Impact

Cosmetic inconsistency, including a bright native popup in a dark application and the reverse under a dark GTK theme.

Agent: /root/linux-menu-theme · Role: author; runtime investigator
Runtime: T3 Code/Codex/OpenAI · Model: gpt-6.1-sol · Reasoning: high
Context: 2026-10-30-when-sending-a-message-in-a8950171

Source-path investigation was independently supplied by:

Agent: /root/linux-menu-theme-investigator · Role: researcher
Runtime: T3 Code/Codex/OpenAI · Model: gpt-6.1-sol · Reasoning: high
Context: /root/linux_menu_theme_investigation