Community
Participate
Working Groups
Created attachment 255303 [details] Selection of an item in a list needs focus on its view first System: Gnome 3.16, Adwaita dark, default Eclipse dark theme. A click doesn't seem to reach the item in a list, i.e. set selection on it. It only focuses its view. This results in having to first focus the view and then click on an entry to get it selected. Double-clicking on an Navigator item while having focus on an editor window opens the currently selected entry, no matter what item was actually double-clicked. Right clicks are also affected, e.g. showing properties for the currently selected file instead of the clicked one. This confuses me a lot. ;) Double-clicks on folders in the Navigator are not affected, although the focus is never set to the double clicked entry. Folding / expanding arrows work as well without updating selection.
This bug sort of references bug 312568, comment 66
After some more experiments, I'm able to reproduce this bug now. It seems specific to the Eclipse Dark theme. I.e, it doesn't occur when the regular theme is activated. It doesn't occur if you manually switch on adwaina from GtkInspector, only if you change theme in the Eclipse PlatformUI switcher. This is the first time I see that a theme makes a functional difference. I'll investigate if it's related to bug 312568.
I checkout SWT before bug 312568 (Double click patch). The issue described in this bug still occurs (with double-clicking not moving the cursor to the editor anymore). As such, the issues don't appear to be directly related to each other. (But it did look very related at first I must say).
I tested with native SWT snippets by calling OS.setDarkThemePreferred(true);, but the issue doesn't occur. It may be some stray listener in Platform U.I. Does this issue occur on Win32/Cocoa? (Would anyone be able to test?)
Can you guys point me to the buildId of the Eclipse you've reproduced this on along with the OS ?
*) Debian/unstable *) Gnome 3.16 *) default Eclipse dark theme *) Eclipse: Version = Mars Release (4.5.0), Build id = 20150621-1200
(In reply to Alexander Hofbauer from comment #6) > *) Debian/unstable > *) Gnome 3.16 > *) default Eclipse dark theme > *) Eclipse: Version = Mars Release (4.5.0), Build id = 20150621-1200 Can you confirm that you can not reproduce this for the package explorer? Only for Navigator?
Sorry, this was vague. I only took the Navigator as an example, in fact I can also reproduce this e.g. with explorers or the breakpoints view.
Yes, I can reproduce on package explorer also. My test env: Eclipse: Version: Neon (4.6) Build id: N20150719-2000 Fedora 22. Gtk 3.16.5 I did some more testing across different Gtk versions and observed that this issue only starts to appear in Gtk 3.14 Dark theme on: - Gtk 2.24 # Double click Issue does not occur, although right click impaired - Gtk 3.10 # Double click Issue does not occur, although right click impaired - Gtk 3.12 # Double click Issue does not occur, although right click impaired (Tested with/without OS CSS). - Gtk 3.12 # Double click Issue does not occur, although right click impaired - Gtk 3.14 # Problem starts to occur with double click as well as right click - Gtk 3.16 # Problem ..... So the issue is in two parts. 1) Right click does not work on dark theme (in any version of gtk, including Gtk2.24) 2) Double click does not initiate focus on Package explorer, (This issue starts to occur Gtk3.14 and onwards) Bug (1) may be some Platform U.I issue. Perhaps we should pursue this in a separate bug. Bug (2) seems to be burrowed in SWT. The difficulty is to reproduce the issue on SWT level now. I tested with the double-click snippet from bug 312568, but could not reproduce the issue. If someone has ideas / snippet on how to reproduce this on SWT level, it would be great.
This was a fun one. So it turns out the issue is with this line in the dark css: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree//bundles/org.eclipse.ui.themes/css/e4-dark.css#n139 If you remove that line everything works fine. Now I'm no css expert but it smells like the engine, while activating, is trying to set this background color and for some reason it is failing and giving up on the activation. I will move this to platform.ui to ask our CSS guys if they have any hint. Thanks for the help so far.
Lars any opinion on this issue?
(In reply to Sopot Cela from comment #11) > Lars any opinion on this issue? Brian, could you have a look? You are our CSS expert
So I saw similar behaviour with font changes as in bug 422894. Basically the CSS engine re-applies font and colour choices whenever some conditions change (e.g., focus, activation). Selecting a part may result in multiple re-applications. In bug 422894, the font change (on a Tree, I think) caused some kind of interference with the selection event. Unfortunately the exact details now fails me. Most but not all SWT widgets ignore calls to set* when they have no change. Hence our workaround was to endow some Helper classes with setFont/setBackground/setForeground wrappers that first check whether the font / colour change was actually necessary. (CSSSWTFontHelper, CSSSWTColorHelper). It may be that retrieving the colour or font is now problematic on some versions of GTK 3.x? It may be that the approach used in bug 435061, disabling redraws, might workaround the issue? You should probably be able to hack the CSSSWTFontHelper and CSSSWTColorHelper to not short-circuit the font / colour changes.
I took a look at this on Fedora 22, and it's the same problem seen on bug 422894 except with the background colour rather than the font. The problematic section of the CSS is .MPartStack.active Tree, [. . .] { background-color: #262626; Unfortunately this can't be worked around using the technique from bug 422894 as the e4-dark.css really does specify a different background colour for parts with and without focus. Deferring redraws as per bug 435061 doesn't help either as the there is no layout in progress. I wonder if the SWT CSS engine should defer triggering its work with an asyncExec so as to avoid any event interference.
Excuse my rather unqualified comment, but not applying background colour changes seems to be a fair workaround for me until this issue can be properly addressed. As it stands now using the dark theme is really frustrating and I couldn't notice the background colour change on focus (or the lack thereof) after commenting out the line.
Other developers are hitting similar issues too: https://www.eclipse.org/forums/index.php/t/1069929/ https://www.eclipse.org/forums/index.php/t/886234/
Too late for 4.5.2. Please retarget if you plan to work on this.
I was unable to find e4-dark.css in the installation folder of Neon Release Candidate 3 (4.6.0RC3): [rli@rlinux eclipse]$ find . -name e4-dark.css [rli@rlinux eclipse]$ => Where is the .css file (so that I can remove the problematic lines)?
I have commented out the css rule(lines 139-143) and the problem goes aways. The css file is located on: eclipse/plugins/org.eclipse.ui.themes_1.1.100.v20160411-1921/css/e4-dark.css I'm using Eclipse 4.6 Neon on Ubuntu 16.04
Using eclipse-installer, I installed eclipse into /usr/local/eclipse/java-neon. There is no e4-dark.css in the plugins directory: [rli@rlinux plugins]$ pwd /usr/local/eclipse/java-neon/eclipse/plugins [rli@rlinux plugins]$ ls org.eclipse.equinox.launcher_1.3.200.v20160318-1642.jar Nor in fact anywhere: [rli@rlinux eclipse]$ pwd /usr/local/eclipse/java-neon/eclipse [rli@rlinux eclipse]$ find . -name e4-dark.css
I installed eclipse for JEE developer from some this mirrors: http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/neon/R/eclipse-jee-neon-R-linux-gtk-x86_64.tar.gz
*** Bug 507081 has been marked as a duplicate of this bug. ***
Although we've worked around this bug, the underlying cause is still there.
The first comment from Bug 507081 is useful in narrowing this down: (In reply to Lars Vogel from comment #0) > If we change our dark theme to style also the active tree, you cannot select > the tree node with one click. > > .MPartStack.active Tree, > .MPartStack.active CTabFolder Canvas { > background-color: #262626; > color: #CCC; > } > > Test description: > > * Download new(ish) Eclipse > - In my case: Version: Oxygen (4.7) Build id: N20160718-2000. (Gtk3.20) > * Turn on Dark theme > * Restart Eclipse > * Click on editor > * click on some project in project explorer > > Expected result > * Project under mouse is selected > > Actual result > * Project explorer receives focus, but project (or file etc..) is not > selected. A second click is required for item to be selected. > > See Bug 499515 for details.
Leo: see comment 13 and 14. I'm a bit loathe to use an asyncExec() — more asynchrony is never a good thing. An alternative approach might be to turn the E4 CSS property handlers to stick in GTK CSS on GTK.
(In reply to Brian de Alwis from comment #25) > Leo: see comment 13 and 14. I'm a bit loathe to use an asyncExec() — more > asynchrony is never a good thing. > > An alternative approach might be to turn the E4 CSS property handlers to > stick in GTK CSS on GTK. Adding Eric to CC, as Eric knows more about the CSS business. I haven't worked much with CSS lateley, I can't give a good approach without some extra research at the moment. Currently I'm working on the Webkit2 port and after the Wayland port, so it would be a while before I get to theaming issues.
CCing Ian as he did some work on CSS.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This still seems to be occuring in my E4 application, reopening to investigate
