Skip to content

fix(ui): make dropdown choices readable in dark JupyterLab themes - #497

Merged
mbektas merged 3 commits into
plmbr:mainfrom
FelipeRamos-neuro:fix/select-dark-theme
Sep 24, 2026
Merged

mbektas merged 3 commits into
plmbr:mainfrom
FelipeRamos-neuro:fix/select-dark-theme

Conversation

@FelipeRamos-neuro

Copy link
Copy Markdown
Contributor

Summary

Makes the chat mode dropdown (and the other NBI selects' option lists) readable in dark JupyterLab themes.

Closes #496

Problem

.chat-mode-select had background-color: initial with a theme-derived text color. In a dark theme that is light text on a transparent select, and since JupyterLab sets no color-scheme, the browser paints the native option popup on its default light palette. The choices are near-invisible.

Solution

  • The chat mode select gets the footer's own background (--jp-cell-editor-background), so it looks as it did when transparent. An explicit color is what stops the popup falling back to the light palette. I first used the input background, which made it a lighter chip in dark themes; the footer background avoids that change.
  • The chat mode <option> matches that select, so the closed and open states are the same tone.
  • The option lists of the form-field, settings-dialog and perf-panel selects get explicit theme colors (--jp-layout-color2 / --jp-ui-font-color0). Every fallback chain ends in --jp-layout-color1 then Canvas/CanvasText, so a theme that leaves a variable out does not bring the bug back.

I mapped all 22 <select> elements in src/; each falls under one of these four containers. A new select outside them would need its own rule.

Testing

  • tests/ts/select-theme-css.test.ts pins the declarations. It fails on the old CSS and passes on the new. It reads the stylesheet text, so it checks the declarations exist, not that they take effect.

  • Checked in headless Chrome by loading the real theme CSS with the old and new base.css and reading computed styles, in the default light and dark themes, jupyterlab-night 0.5.2, and a theme defining almost nothing:

    Theme Before (popup) After
    Light readable unchanged look
    Dark white text on the default light popup, ~1:1 white on #212121, same tone as the footer
    Night #f0f6fc on the default light popup, ~1.1:1 #f0f6fc on #0d1117, same tone as the footer
    Near-empty theme not checked readable through the fallbacks

    The "before" popup color assumes the browser's default light popup, inferred from the missing color-scheme.

  • jlpm jest (580 passed), jlpm tsc --noEmit, jlpm lint:check and pytest tests/ are clean. The full pytest run was last done on the tour branch; this change is CSS and a Jest test only.

Not checked: the painted native popup (headless Chrome cannot render it), Firefox, and macOS, where the native menu may follow the OS appearance instead of the page.

🤖 Generated with Claude Code

FelipeRamos-neuro and others added 2 commits September 21, 2026 18:16
The chat mode select reset its background to initial while keeping the theme's
text color, so in a dark theme the native option list showed light text on a
light popup. Give it the themed input background and set explicit theme colors
on the option lists of the NBI selects (chat mode, form fields, settings
dialog, perf panel), which browsers that draw options from their own colors
would otherwise leave on the light palette.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-ups from review of the dark-theme fix:

- Give the chat mode select the footer's own background instead of the input
  background, so it looks as it did when it was transparent (the input
  background made it a lighter chip in dark themes). An explicit color is what
  keeps the native popup from falling back to the light palette.
- Match the chat mode popup to that select so the closed and open states are
  the same tone.
- Add fallbacks to the option colors so a theme that omits a variable does not
  leave the options transparent and bring the original bug back.

Checked against the default light and dark themes and jupyterlab-night 0.5.2
in headless Chrome, plus a theme that defines almost nothing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@pjdoland pjdoland added the bug Something isn't working label Sep 22, 2026
@mbektas
mbektas merged commit ca2e2c5 into plmbr:main Sep 24, 2026
4 checks passed
@FelipeRamos-neuro
FelipeRamos-neuro deleted the fix/select-dark-theme branch September 25, 2026 14:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Chat mode dropdown is unreadable in dark JupyterLab themes

3 participants