Community
Participate
Working Groups
Created attachment 281543 [details] The two screenshots Going into Window > Preferences > General > Editors > Text Editors and setting the Background color option and then clicking "Apply" renders correctly while the Preferences dialog box is open, but upon clicking "Apply and Close", the background color resets. However, the newly selected color is still visible behind the line numbers; only the actual code section resets to the theme color. I've attached two screenshots side-by-side. In the first, you can see that setting the background color to blue and then clicking "Apply" updates the entire editor as expected. However, upon clicking "Apply and Close" the second screenshot shows that the bulk of the editor (save for the line numbers) have reverted to the default dark gray from the dark theme. This behavior did not happen in 2019-09. Tested in 2019-12 on latest Windows 10.
Can reproduce on master. What is interesting: this seem to be only related to the Dark theme. The editor bg color *is* saved (the preference shows changed value after re-opening), but only the line number ruler changes the color, NOT the rest of the editor. The Light theme (and all others except Dark) seem to be not affected. The main difference is that only in the Dark theme the background color does NOT match system default, so probably the handling of the color if this flag is off is logically incorrect. Also if interest: the part of the Java editor between line numbers and text, where the "+" and "-" toggle handlers are located, is never properly colored to the custom background, in *all* themes. However, in Dark theme it makes a biggest visual difference.
Another observation: The background color is correctly applied from preferences. Only when the editor gains focus, the background color is reverted to the default color of the dark theme. Also an similar issue exists for the console, see bug 514059.
*** Bug 561329 has been marked as a duplicate of this bug. ***
Confirming issue. Was in process of writing up bug when i found this one. The issue seems to have appeared as of 2019-09 (4.14). I have attached a screenshot sowing an older version 2019-03 (4.11) compared against dark and light versions of 2019-09 (4.14) with the related background color codes. Possibly related to the updates on at the end of the New and Noteworthy for 4.14 release here: https://www.eclipse.org/eclipse/news/4.14/platform.php "Usage of consistent colors for the dark theme The usage of different shades of gray in the dark theme was reduced. The styling of the widgets is also not based on the selected view anymore, which makes the UI more consistent."
Created attachment 282540 [details] Dark theme display with incorrect background color this image is described in this comment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=559321#c4
This bug still exists as of the following Eclipse version: Version: 2020-09 (4.17) Build id: I20200902-1800 This is quite frustrating. Please fix this regression! For the afflicted, some workarounds can be found here: https://stackoverflow.com/questions/59599251/eclipse-2019-black-background and here: https://stackoverflow.com/questions/60450156/eclipse-4-14-0-changing-the-editor-background-colour Note that this bug report may be a duplicate of bug 558782.
I am still seeing this problem on: Version: 2021-12 (4.22) Build id: I20211124-1800 OS: Windows 10, v.10.0, x86_64 / win32 I would love for this to be fixed so that I don't have to manually modify obscure config files each time I upgrade eclipse! Please fix this!
*** Bug 578292 has been marked as a duplicate of this bug. ***
Isn't this a duplicate of bug 464226? Clearly the CSS styling somehow overrides the preference.
(In reply to Thomas Wolf from comment #9) > Isn't this a duplicate of bug 464226? Clearly the CSS styling somehow > overrides the preference. Bug 464226 was validated to be fixed, but indeed it re-appeared (see regression keyword), versions 4.5m7-4.14 should be fine. There might be an similar root cause this time, but that needs separate investigation. So I think it is best to use this new bug report for that investigation.
A robust solution would be to remove the hard-coded color of the Editor backgrounds from the CCS and use the preferences from Colors and Fonts. Although the Editor background configuration is currently in General > Editors > Text Editors > Appearance color options, see Bug 531033, which might need fixing first. Lars did this for the tab colors, see c6ce5643aa4a95e49f5d4029bbe5502312ce8160 in particular bundles/org.eclipse.ui.themes/css/dark/e4-dark_ide_colorextensions.css.
*** Bug 558782 has been marked as a duplicate of this bug. ***
As pointed out in bug 558782 comment 18, this is caused by https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/152281 . When I remove .MPart Composite > *, .MPart Composite > * > *, from e4-dark_partstyle.css *and* Composite > *, Composite > * > *, from e4-dark_globalstyle.css, the editor displays as it should using the color set in the preferences. Don't know what other effects removing this may have. Bug 558782 is another duplicate?
(In reply to Thomas Wolf from comment #13) > As pointed out in bug 558782 comment 18, this is caused by > https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/152281 . > > When I remove > > .MPart Composite > *, > .MPart Composite > * > *, > > from e4-dark_partstyle.css *and* > > Composite > *, > Composite > * > *, > > from e4-dark_globalstyle.css, the editor displays as it should using the > color set in the preferences. > > Don't know what other effects removing this may have. > > Bug 558782 is another duplicate? Removing it would effectively be reverting most of the patch of Bug 552691 again, except for CTabFolder/TabFolder which I wasn't able yet to validate what is the effect of reverting that too. The following snippet seems to solve the problems of Bug 552691 too, without interfering with the TextEditor background colors. Composite { swt-background-mode: default; }
New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/190575
(In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/190575 The commit message editor in the EGit staging view has the same problem. Debugging (breakpoint in StyledText.setBackground()) showed that it first _did_ actually set the background to the preference value, but later the CSS engine called setBackground() again with the theme color. The fix there is simply to disable CSS styling altogether. CSS does update the editor preferences, and the editor reacts on updates to these preferences, so it still obeys the theme, and takes into account any changes a user might make in these preferences. I don't know whether that might be a solution for text editors in general. For EGit's staging view, it is.
Gerrit change https://git.eclipse.org/r/c/egit/egit/+/190575 was merged to [master]. Commit: http://git.eclipse.org/c/egit/egit.git/commit/?id=b07cc4fb86ee71b020e2a7dd6b72f6e3fd22cac7
(In reply to Thomas Wolf from comment #16) > (In reply to Eclipse Genie from comment #15) > > New Gerrit change created: https://git.eclipse.org/r/c/egit/egit/+/190575 > > The commit message editor in the EGit staging view has the same problem. > Debugging (breakpoint in StyledText.setBackground()) showed that it first > _did_ actually set the background to the preference value, but later the CSS > engine called setBackground() again with the theme color. > > The fix there is simply to disable CSS styling altogether. CSS does update > the editor preferences, and the editor reacts on updates to these > preferences, so it still obeys the theme, and takes into account any changes > a user might make in these preferences. > > I don't know whether that might be a solution for text editors in general. > For EGit's staging view, it is. A similar approach was suggested in https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/188920 However, this requires every editor to disable CSS styling. But the opposite should be the default, CSS should not try to style every viewer of be aware what not to style. See Comment 14 for a solution that seems to work correctly, but needs testing.
(In reply to Rolf Theunissen from comment #18) > A similar approach was suggested in > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/188920 The problem with that change is that this is not the right place. You have to do this in createPartControl(), and only if getPreferenceStore() != null. Then it works out of the box for any AbstractTextEditor. (And also covers cases where CSS might define a font, which was overridden by the preferences.)
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190677
(In reply to Eclipse Genie from comment #20) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/190677 Just to show what I mean. To me, this is not a "work-around". It's a needed fix: CSS sets the preferences, the editor updates, and then something else triggers a reskin/re-application of CSS, and all the styling from the preferences is overpainted. This clearly shows that text editors should simply not be styled via CSS.
I am still seeing this problem on: Eclipse SDK Version: 2022-06 (4.24) Build id: I20220607-0700 This is quite frustrating. This problem has existed for 2.5 years now. I am still having to manually modify obscure config files each time I upgrade eclipse just so I can get dark mode to work! Please fix this! For those afflicted, please see comment 6 which lists some workarounds.
(In reply to Derek Foster from comment #22) > I am still seeing this problem on: > > Eclipse SDK > > Version: 2022-06 (4.24) > Build id: I20220607-0700 > > This is quite frustrating. This problem has existed for 2.5 years now. I am > still having to manually modify obscure config files each time I upgrade > eclipse just so I can get dark mode to work! Please fix this! > > For those afflicted, please see comment 6 which lists some workarounds. Could you suggest a change via a pull request?
Same here. The issue persists!
The issue appears only when a source is not open as a tab in teh editor, and you open a new existing source file. then it opens with the background white, instead of black.
Bug still exists in 4.28.0
It is still in 4.29.0. Come on guys, this is almost a 4 year old bug!!!!!!!!!
(In reply to Adam Szalontai from comment #27) > It is still in 4.29.0. > > Come on guys, this is almost a 4 year old bug!!!!!!!!! Can you help testing? (In reply to Adam Szalontai from comment #27) > It is still in 4.29.0. > > Come on guys, this is almost a 4 year old bug!!!!!!!!! I migrated Thomas Gerrit to a PR, see https://github.com/eclipse-platform/eclipse.platform.ui/pull/1349 Can you please test that this solve the reported bug?
(In reply to Lars Vogel from comment #28) > (In reply to Adam Szalontai from comment #27) > > It is still in 4.29.0. > > > > Come on guys, this is almost a 4 year old bug!!!!!!!!! > > Can you help testing? (In reply to Adam Szalontai from comment #27) > > It is still in 4.29.0. > > > > Come on guys, this is almost a 4 year old bug!!!!!!!!! > > I migrated Thomas Gerrit to a PR, see > https://github.com/eclipse-platform/eclipse.platform.ui/pull/1349 > > Can you please test that this solve the reported bug? Please use https://github.com/eclipse-platform/eclipse.platform.ui/pull/1036 for testing.
Adam, https://github.com/eclipse-platform/eclipse.platform.ui/pull/1036 has been merged, please test with tomorrows I-Build from https://download.eclipse.org/eclipse/downloads/
