Repository navigation
[Bug]: Desktop context menus do not inherit imported VS Code themes #10997
Description
Before submitting
- I searched existing issues and did not find a duplicate of this specific imported-theme bug. Related closed issue Linux context menus and dialogs should use a custom design #333 is linked below.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Summary
Desktop application context menus do not inherit the active imported VS Code theme palette. The main UI adopts the imported colors, but the thread context menu keeps the native menu colors. Importing a theme therefore leaves a visible part of the application unthemed.
Steps to reproduce
- Open the T3 Code desktop app.
- Import and select a dark VS Code theme with a visibly colored palette, such as a blue background, through the theme settings.
- Right-click a thread in the sidebar.
- Compare the menu background, text, separators, and selection colors with the selected theme. Open a submenu such as Snooze or Copy as well.
- Switch to another imported theme with the same dark appearance but different colors, then reopen the menu.
Expected behavior
Application context menus and their submenus use the active imported theme's corresponding palette colors and update when the selected theme changes.
Actual behavior
With an imported blue theme active, the sidebar uses the imported colors, but the thread context menu remains grey.
Source inspection explains the desktop mismatch: selecting a custom palette updates the web UI, while the desktop menu path receives only a light, dark, or system appearance setting.
Impact
Cosmetic issue. Imported themes render inconsistently across the application's own controls.
Version or commit
Source inspected at 061543e9e5b54ec0048725c37d52fef2962df173. The affected installed build was not independently identified. No fresh interactive reproduction was performed during this investigation.
Environment
Desktop application context-menu path. Exact release and OS version were not captured with the report.
Source evidence
localApi.tsroutes desktop context menus throughdesktopBridge.showContextMenu; browser clients useshowContextMenuFallback.ElectronMenu.tsbuilds and opens an Electron menu without the imported palette.DesktopThemeSchemacarries onlylight,dark, orsystem.ElectronTheme.tsapplies that setting toElectron.nativeTheme.themeSource.- The existing browser context menu uses application theme variables. This provides a reference for the expected palette integration.
Scope and related issue
This report covers application context menus and their submenus when an imported VS Code theme is active. Native filesystem dialogs and syntax highlighting are outside its scope.
#333 previously requested custom Linux menus and dialogs. It was closed with a comment stating that application context menus had been replaced. This fresh report isolates imported-theme inheritance, which the current desktop menu path still does not provide.
Workaround
The browser client uses a menu that reads the application theme variables, according to source inspection. That workaround has not been verified interactively for this report.
Activity
juliusmarminge commentedon Sep 9, 2026
Thanks for isolating this from #333 and for the source pointers. Confirmed on current
main: this is a real desktop chrome mismatch, not a duplicate of the closed Linux custom-menu request.What happens today
Selecting an imported VS Code theme updates the web UI palette (
applyThemePalette/ CSS variables). The desktop shell only receiveslight|dark|systemviaDesktopThemeSchema→desktopBridge.setTheme→Electron.nativeTheme.themeSource.Application context menus on desktop never see that palette.
localApirouteswindow.desktopBridgetoElectronMenu.showContextMenu, which builds a nativeMenuand pops it with no colors. The browser path (showContextMenuFallback) already uses application theme variables (dropdown-glass,--contrast-popover-foreground,--contrast-border). Switching between two dark imported themes therefore changes the sidebar and leaves the thread menu (and Snooze/Copy submenus) on native grey.Electron has no API to paint native menus with a custom workbench palette, so this is not a missing hex in the current IPC.
Not the same as
tokenColors.Prior attempts
PRs that routed desktop through the themed HTML menu were closed without merge: #280, #6440 (Windows/Linux HTML, macOS native), #7998 (desktop → glass menu). Those were broader than this report and were not taken forward as written. Julius has also preferred keeping native macOS menus.
Next
Keep this open for a product call before anyone implements it.
Filesystem dialogs and syntax highlighting stay out of scope, as the report says. Any HTML-menu change should account for #10390 and #10504 so we do not regress native focus or icon work.
TonybynMp4 commentedon Oct 3, 2026
One more option for the product call: make it a desktop-only Appearance setting, Context menus: Native / App, defaulting to Native.
I'd really be interested in this because the native menu really sucks compared to the web version.
TonybynMp4 commentedon Oct 17, 2026
@juliusmarminge could you weigh in on the setting above when you get a chance?
i made the setting and it's ready for a PR if you want it.
swsammy commentedon Nov 14, 2026
+1 for the Context menus: Native / App setting @TonybynMp4 proposed above, with Native as the default.
On KDE Plasma 6.6 (Wayland), the native menu is drawn by Chromium from the GTK theme, so it matches neither the app nor the desktop. It's awful. Setting Breeze as the GTK theme only gets it partway.
I also tried the App menu on desktop with a local patch, styled with theme Custom CSS (#35247) to copy Breeze. What I found:
Side by side, the App menu still looks wrong next to a real KDE menu:
It's still better than today's native menu, which follows neither T3 Code's theme nor the desktop, so I'd switch to the App option for context menus as soon as it ships.