Skip to content

Fix: Mindwork Studio can miss the change from light to dark mode - #991

Merged
SommerEngineering merged 4 commits into
MindWorkAI:mainfrom
SimonBpunkt:fix/Darkmode-switch
Sep 22, 2026
Merged

SommerEngineering merged 4 commits into
MindWorkAI:mainfrom
SimonBpunkt:fix/Darkmode-switch

Conversation

@SimonBpunkt

Copy link
Copy Markdown
Contributor

As mentioned in the ticket: i could not recreate bug as described in the ticket but instead fixed the OS lighting mode taking precedence over the mindwork studio setting.

@SommerEngineering

Copy link
Copy Markdown
Member

Thanks, Simon — you found a real bug. With a fixed color theme, the system's light or dark mode did win over the app setting. Unfortunately, the guard in SystemeThemeChanged only hides it until the next render. So I added two commits to this PR.

Why the guard doesn't hold

  • When the OS switches, MudBlazor's MudThemeProvider.SystemDarkModeChangedAsync first writes the new mode into its own state (_isDarkModeState.SetValueAsync). Only then does it call our handler. The guard runs too late to prevent that.
  • A later render doesn't undo it either. MudBlazor's ParameterState takes over IsDarkMode only when the value changes compared to the last one. With a fixed theme, it never changes.
  • Before your change, our handler re-rendered right away, so the wrong palette showed up at once. With the guard, it shows up at the next render of MainLayout, e.g. when you click another page in the navigation. That's why it looked fixed in a quick test.

The fix binds ObserveSystemThemeChange to the setting. MudBlazor now watches the OS only while "System" is selected (50c686a).

The bug from the ticket

This one is about "System" plus sleep. MudBlazor's JS listener reports a theme change exactly once (invokeMethodAsync). When the machine wakes up, that report often arrives while the SignalR connection is still down, and Blazor drops it without retrying.

Before #849, this went unnoticed. The circuit was gone after the sleep, the page reloaded, and MainLayout read the OS theme anew. Since #849, the circuit survives the sleep and is only reconnected, so nobody asks the OS again.

CircuitStateService now raises ConnectionRestored when the connection comes back, and MainLayout then reads the theme again (fde10ef). It must not await the JS call there: the event fires inside the reconnect handshake, and the browser's answer can only be processed after the handshake ends.

Reproducing it without sleeping (debug build, Web Inspector):

  1. Call stopWatchingDarkThemeMedia() to simulate the lost report.
  2. Switch the OS theme. The app keeps its old theme.
  3. Call Blazor.disconnect(). After the reconnect, the app follows the OS again.

@SommerEngineering
SommerEngineering merged commit c4ba83f into MindWorkAI:main Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants