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

Switch between dark/light mode doesn't take effect until user logs out and back in #15630

Closed
jhammond-git opened this issue Apr 4, 2024 · 5 comments
Assignees
Labels
beta Concerns a bug/feature in a beta release severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@jhammond-git
Copy link

Deployment Type

Self-hosted

NetBox Version

v4.0-beta1

Python Version

3.10

Steps to Reproduce

  1. Log in as a user.
  2. Click on the User menu in the top right
  3. Click Preferences
  4. Change color mode, and click Save at the bottom

Expected Behavior

Color mode changes as soon as Save is clicked and the page refreshes to the new mode.

Observed Behavior

Color mode doesn't change until user logs out of Netbox and back in.

@jhammond-git jhammond-git added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Apr 4, 2024
@jhammond-git
Copy link
Author

I went back to my production (3.7.4) and discovered it does the same in the Preferences menu, but also found the menu item for light/dark mode switch which takes effect immediately. That led me to the button which I noticed in beta that has the same function, but I didn't realize it was a button before.

Having said all that, I don't see why the preference can't change mode on Save, but I can also see why that wouldn't be a reasonable use of development time.

@jeffgdotorg
Copy link
Collaborator

The first time I tried to reproduce this issue (going from dark to light), it behaved as expected. Each subsequent time I was able to reproduce it consistently regardless of which direction the color mode was going.

@jeffgdotorg jeffgdotorg added severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Apr 8, 2024
@Julio-Oliveira-Encora
Copy link
Contributor

When the color mode is changed in User Preferences, you must log out and log in again for the changes to be applied. On the other hand, if you select "Dark" or "Light" on Preferences, the change is applied at the same time.

If you want to apply the changes as soon as the color mode changes, please assign this ticket to me.

@jeremystretch jeremystretch added the beta Concerns a bug/feature in a beta release label Apr 19, 2024
@jeffgdotorg jeffgdotorg removed their assignment Apr 19, 2024
@jeremystretch jeremystretch added the status: accepted This issue has been accepted for implementation label Apr 19, 2024
@jeremystretch jeremystretch self-assigned this Apr 22, 2024
@jeremystretch
Copy link
Member

The root issue is that the user preference is stored on the backend, whereas the live toggle (the button at top right) saves its setting in local storage. So we can end up with a conflicting state where the user's preference indicates dark mode but local storage indicates light mode, or vice versa.

Honestly it feels like overkill to track light/dark mode as a preference anyway. I can easily see this being device- or time-dependent, and the live toggle makes much more sense IMO. Maybe we should just ditch the stored preference altogether.

@DanSheps
Copy link
Member

Honestly it feels like overkill to track light/dark mode as a preference anyway. I can easily see this being device- or time-dependent, and the live toggle makes much more sense IMO. Maybe we should just ditch the stored preference altogether.

The one arguement I could see is that if you move to new devices frequently, however I think that is a corner case and not the norm so we might not even care about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta Concerns a bug/feature in a beta release severity: low Does not significantly disrupt application functionality, or a workaround is available 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

5 participants