-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Different theme choice in different profiles affects other profiles #5373
Comments
Yes, I think this is the limitation of current chromium architecture because dark mode is managed in ui layer and there is no profile concept in that layer. |
@simonhong edge canary 77.0.228.0 (based on chromium) has the same issue! |
right, I saw that. Need to think how to overcome :) |
Other ways to reproduce
From me using High Sierra:
|
@simonhong were you still checking this and #5557 out? (if not, maybe you can un-assign yourself. Thanks! 😄) |
@rebron @bsclifton @petemill Brave theme inconsistency can happen easily when a user uses multi profiles. |
Yes I agree @simonhong. It's not possible to align native theme properly otherwise. |
@simonhong I like that approach 😄 |
++ on @simonhong suggestion |
Thanks for feedback @LaurenWags @bsclifton @petemill :) |
something we should consider when checking upgrade cases - if a user is currently in a position where one or more profiles have different themes set, which one gets globally set on upgrade? I'd probably vote the theme on the Default profile, but unsure if there are other things to consider here? |
@LaurenWags Migrating theme option from profile to local state(global pref) will be done only once. |
As long it's documented which one we should expect I'm good with whatever 😄 thanks @simonhong! |
I used same policy for migrating Widevine prefs. |
With this, we can fix brave theme related bugs with multi profile because all profiles use browser-wide prefs. So far, system theme could be changed whenever new profile is used because brave theme was profile prefs but system theme is browser wide setting. And did cleanup and refactoring. Refactoring point is separation of theme managing and dark mode managing. So far, theme service has all dark mode handling logic. But I think theme service handles browser theme with underrlying dark mode. So, all dark mode logic is in dark_mode namespace. fix brave/brave-browser#5373 fix brave/brave-browser#5557
With this, we can fix brave theme related bugs with multi profile because all profiles use browser-wide prefs. So far, system theme could be changed whenever new profile is used because brave theme was profile prefs but system theme is browser wide setting. And did cleanup and refactoring. Refactoring point is separation of theme managing and dark mode managing. So far, theme service has all dark mode handling logic. But I think theme service handles browser theme with underrlying dark mode. So, all dark mode logic is in dark_mode namespace. fix brave/brave-browser#5373 fix brave/brave-browser#5557
Verification passed on
Verification passed on
Verification PASSED on
|
It would actually be nice for Brave to support different theming in different profiles. I like to separate work and private browsing. When having different themes in profiles, I can immediately know which profile I'm on so that I don't accidentally share my browsing history when on screen sharing for instance. |
When having multiple profiles, if profile A changes the preference for Theme, profile B is affected.
Test plan / Steps to Reproduce
--> Observe Profile A and Profile B have same theme (light or dark)
Expected
Profile B change to Dark. Profile A stays light - both the browser toolbar, and the Settings page background.
Actual
Profile B and Profile A both change to Dark - both the browser toolbar and the Settings page background.
The text was updated successfully, but these errors were encountered: