[GTK] Double click behaviour changed between 2025-03 and 2025-09

[stephan-herrmann]

Describe the bug

As reported by @haubi in eclipse-egit/egit#110 a double click into the EGit Staging View may fail to select the element under the cursor, and will instead operate on the previously selected tree element.

Since EGit doesn't seem to have any recent related changes fingers are pointing to SWT for changed behavior.

To Reproduce

• Have a git staging view with several staged files
• Select the first file
• Select any editor or other view
• Perform a double click on the second file in the staging view

Expected behavior
A compare editor should open for the second file.

Actual behavior
Compare editor will open for the first file.

Environment:

1. Select the platform(s) on which the behavior is seen:

• • All OS
• • Windows
• • Linux
• • macOS

EGit committer tried to reproduce on macOS and failed.

2. Additional OS info (e.g. OS version, Linux Desktop, etc)

I'm seeing it on Ubuntu 24.04.3 with

org.eclipse.swt.internal.gtk.theme=Breeze:dark
org.eclipse.swt.internal.gtk.version=3.24.41
org.eclipse.swt.internal.webkitgtk.version=2.48.7
osgi.ws=gtk

and

GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/stephan/.gtkrc-2.0:/home/stephan/.config/gtkrc-2.0
GTK_OVERLAY_SCROLLING=0
GTK_RC_FILES=/etc/gtk/gtkrc:/home/stephan/.gtkrc:/home/stephan/.config/gtkrc
SWT_GTK3=1
SWT_GTK4=0

3. JRE/JDK version

java.version=24.0.1

Version since
Reported in eclipse-egit/egit#110:

• working: SWT 3.129.0.v20250221-1734
• broken: SWT 3.131.0.v20250820-1556

Workaround (or) Additional context

One additional click is required to first set focus to the staging view.

See eclipse-egit/egit#110

[ptziegler]

Whatever is causing this has to be very likely be on the EGit side, not the SWT side. Specifically something introduced with 7.4.

This is the 2025-06 with EGit 7.3, where the staging view behaves as expected:

Recording.1.mp4

This is the same 2025-06, this time with EGit 7.4, where the described behavior occurs:

Recording.2.mp4

[ptziegler]

Not in the video, but using the 2025-12 M2 with EGit 7.3 also behaves as it should. If you look closely at the recording, you'll notices that the staging view "lights up" when clicking on it, which doesn't happen with the 7.3. Some change there must cause the view to gain focus.

[ptziegler]

Caused by eclipse-egit/egit@ec96081

[iloveeclipse]

Caused by eclipse-egit/egit@ec96081

Theme / css changes??? How that?
The only other one https://github.com/eclipse-egit/egit/blob/ec960817dc4b0b6e303df506e0d37858a5bbe25d/org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/history/CommitAndDiffComponent.java#L100 is probably not relevant.

[ptziegler]

I can only report what I'm seeing. But the issue is definitely the result of this CSS class:

.MPartStack.active .MPart Form Composite Section Tree.org-eclipse-egit-ui-StagingView {
	background-color: #FFFFFF;
}

[ptziegler]

I can only report what I'm seeing. But the issue is definitely the result of this CSS class:

.MPartStack.active .MPart Form Composite Section Tree.org-eclipse-egit-ui-StagingView {
background-color: #FFFFFF;
}

I can even go one step further. It happens with .MPartStack.active but not with .MPartStack

[iloveeclipse]

I would then say it's platform (UI/SWT) bug. Css styling shouldn't affect focus in ideal world.
But I assume the problem is somewhere between setting background on widgets where "touching" GTK widgets in different order (or for the first time) changes key focus or triggers extra events that steal focus or something like that.

[laeubi]

I noticed the same. Even worse in the History view (that should be pure platform?) it happens that one is unable to select multiple lines and therefore can not squash items sometimes!

The strange thing is that one can "fix" it by restart Eclipse but then it happens again (maybe after some time or when switching Views/Perspectives). This is very annoying.

[laeubi]

Theme / css changes??? How that?

I have let Copilot doing some guess here and it says:

Root Cause

When setBackground() is called on a Tree widget (triggered by CSS styling from Eclipse's active part stack), GTK may grab focus to the widget during the CSS application process:

• setBackgroundGdkRGBA() is called with the widget handle
• gtk_style_context_add_provider() is invoked to apply CSS styling
• GTK realizes the widget if not already realized and may grab focus
• First click of double-click changes focus, second click operates on wrong item

Solution

Temporarily disable widget's focus capability while applying CSS styles:

• Query current focus state using new gtk_widget_get_can_focus() function
• Set can_focus to false before applying CSS
• Apply CSS via gtk_css_provider_load_from_css()
• Restore original can_focus state

This prevents GTK from grabbing focus during CSS application while preserving the widget's normal focus behavior.

---

@akurtakov @jonahgraham I don't know if it makes sense here but maybe gives a first direction of how CSS styling can influence widget focus.

[stephan-herrmann]

GTK realizes the widget if not already realized and may grab focus

I don't know much about SWT, even less about GTK, but how can a widget remain unrealized when the operation is repeated several times and always exhibits the same problem?

[ptziegler]

When setBackground() is called on a Tree widget (triggered by CSS styling from Eclipse's active part stack), GTK may grab focus to the widget during the CSS application process:

• setBackgroundGdkRGBA() is called with the widget handle
• gtk_style_context_add_provider() is invoked to apply CSS styling
• GTK realizes the widget if not already realized and may grab focus
• First click of double-click changes focus, second click operates on wrong item

I've commented out the call to gtk_css_provider_load_from_css and this this does not solve the issue. If I instead replace

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java

Lines 3574 to 3578 in 8c5fcdd

	if (rgba == null) {
	background = defaultBackground();
	} else {
	background = rgba;
	}

with background = defaultBackground(); or

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Tree.java

Lines 1558 to 1567 in 8c5fcdd

	@Override
	GdkRGBA getContextBackgroundGdkRGBA () {
	if (background != null) {
	return background;
	} else {
	// For Tables and Trees, the default background is
	// COLOR_LIST_BACKGROUND instead of COLOR_WIDGET_BACKGROUND.
	return defaultBackground();
	}
	}

with

@Override
GdkRGBA getContextBackgroundGdkRGBA () {
	// For Tables and Trees, the default background is
	// COLOR_LIST_BACKGROUND instead of COLOR_WIDGET_BACKGROUND.
	return defaultBackground();
}

the problem disappears as well. So it has definitely something to do with the background field. I just don't understand how and why.

[laeubi]

@ptziegler just a wild guess, maybe just always call defaultBackground()

 @Override 
 GdkRGBA getContextBackgroundGdkRGBA () { 
 	if (background != null) { 
                defaultBackground();
 		return background; 
 	} else { 
 		// For Tables and Trees, the default background is 
 		// COLOR_LIST_BACKGROUND instead of COLOR_WIDGET_BACKGROUND. 
 		return defaultBackground(); 
 	} 
 } 

to check if it is the method call or if it is the value that makes a difference?

[ptziegler]

@ptziegler just a wild guess, maybe just always call defaultBackground()

 @Override 
 GdkRGBA getContextBackgroundGdkRGBA () { 
 	if (background != null) { 
                defaultBackground();
 		return background; 
 	} else { 
 		// For Tables and Trees, the default background is 
 		// COLOR_LIST_BACKGROUND instead of COLOR_WIDGET_BACKGROUND. 
 		return defaultBackground(); 
 	} 
 } 

to check if it is the method call or if it is the value that makes a difference?

I've already tried that and it works.

Additionally, I've commented out several parts of where this method is called so that it's only called from the CSS engine. The interaction between the CSSPropertyBackgroundSWTHandler and the call to Tree.getBackground()/Tree.setBackground() is somehow responsible for this.

[laeubi]

@ptziegler what about

@Override
GdkRGBA getContextBackgroundGdkRGBA () {
	// When a custom background is set, delegate to Control's implementation
	// which parses from the CSS provider instead of returning the stored
        // background field value directly.
	if (background != null && background != defaultBackground()) {
		return super.getContextBackgroundGdkRGBA();
	}
	// For Tables and Trees, the default background is
	// COLOR_LIST_BACKGROUND instead of COLOR_WIDGET_BACKGROUND.
	return defaultBackground();
}