Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't affect UI theme preference #7599

Closed
Ren60FHk opened this issue Oct 21, 2021 · 4 comments
Closed

Can't affect UI theme preference #7599

Ren60FHk opened this issue Oct 21, 2021 · 4 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@Ren60FHk
Copy link

NetBox version

3.0.8

Python version

3.7

Steps to Reproduce

  1. Set the light theme in Profile & Settings.
  2. Save changes.
  3. Logout.
  4. Clear a browser cache.
  5. Log in.

Expected Behavior

I expect to see the light theme.

Observed Behavior

The theme is dark.

@Ren60FHk Ren60FHk added the type: bug A confirmed report of unexpected behavior in the application label Oct 21, 2021
@jeremystretch
Copy link
Member

I'm not able to replicate this in v3.0.8. Do you have your browser configured to prefer dark mode? Maybe try a different browser?

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Oct 21, 2021
@Ren60FHk
Copy link
Author

Ren60FHk commented Oct 21, 2021

I've tried another browser before posting - same result. But, I've changed a browser internal theme from dark to light and NetBox had replicated that behaviour. Thus, NetBox leans on the browser (maybe even system for someone) color theme.

@jeremystretch
Copy link
Member

I'm not really sure which should take precedence. @thatmattlove any thoughts?

@thatmattlove
Copy link
Contributor

Tricky one. Hopefully a090955 adequately resolves this. The challenge is we have multiple vectors from which to determine the color mode:

  1. System/browser preference (prefers-color-scheme media query) — should be considered the lowest priority, since it's inferred and not explicit. ('system mode' below)
  2. Mode set by UI toggles (not system preference) — should be considered temporary, not persisted to the user's profile, and not persisted across browser sessions. ('client mode' below)
  3. Mode set by system preference — should be persisted in the user's profile and therefore across any of that user's browser sessions. ('server mode' below)

Seems simple on the face, but consider the scenarios:

  • System mode is set through inference, client mode is not set, server mode is not set
  • System mode is set through inference, client mode is set, server mode is not set — which to use?
  • System mode is set through inference, client mode is set, server mode is set, client mode and server mode do not match — which to use?
  • System mode is set through inference, client mode is not set, server mode is set

And, consider that these "problems" are presented on each page load and any time a color mode toggle is used.

Ultimately, I implemented the logic as:

  1. If the mode was inferred and the server mode is set, use the server mode, overriding the inferred mode.
  2. If the client mode is not set and the server mode is, use the server mode, overriding the inferred mode.
  3. If the client mode is set and the server mode is not set, use the client mode, but allow it to be overridden if/when a server mode is set (for example, after login).
  4. If the client mode is set, and the server mode is set, and they are not the same, use the client mode. This is an assumption on my part that the client mode is more recently set via a toggle.
  5. Otherwise, use the inferred mode from the system/browser.
  6. As a last resort in the event of an error or no matching conditions whatsoever, use light mode.

@thatmattlove thatmattlove self-assigned this Oct 27, 2021
@thatmattlove thatmattlove added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Oct 27, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants