Community
Participate
Working Groups
First observed some time in 2010 on GTK. To reproduce: Open Eclipse, double-click on a file in the package explorer. Expected: Editor part is opened and keyboard focus moves there. Observed: Eclipse displays the editor part as being active, but keyboard focus remains in the package explorer. It seems that the SWT Tree widget fires a DefaultSelection event, which Eclipse uses to open the file... but then it fires a MouseDown which causes keyboard focus to move back to the Package Explorer. Seems like an event order issue. Since the MouseDown caused the selection change, I would expect the MouseDown event to arrive prior to the selection change. Here's the stack trace from the second MouseDown event which steals focus from the editor. PackageExplorerPart.setFocus() line: 780 CompatibilityView(CompatibilityPart).delegateSetFocus() line: 204 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 MethodRequestor.execute() line: 56 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 252 InjectorImpl.invokeUsingClass(Object, Class<?>, Class<Annotation>, Object, PrimaryObjectSupplier, PrimaryObjectSupplier, boolean) line: 258 InjectorImpl.invoke(Object, Class<Annotation>, Object, PrimaryObjectSupplier) line: 229 ContextInjectionFactory.invoke(Object, Class<Annotation>, IEclipseContext, Object) line: 107 PartRenderingEngine.focusGui(MUIElement) line: 775 PartServiceImpl.activate(MPart, boolean, boolean) line: 708 PartServiceImpl.activate(MPart, boolean) line: 639 ContributedPartRenderer(AbstractPartRenderer).activate(MPart) line: 106 ContributedPartRenderer$1.handleEvent(Event) line: 62 EventTable.sendEvent(Event) line: 84 Display.sendEvent(EventTable, Event) line: 4449 ContributedPartRenderer$2(Widget).sendEvent(Event) line: 1317 ContributedPartRenderer$2(Widget).sendEvent(int, Event, boolean) line: 1341 ContributedPartRenderer$2(Widget).sendEvent(int, Event) line: 1326 Shell.setActiveControl(Control, int) line: 1727 Tree(Control).gtk_button_press_event(long, long, boolean) line: 3076 Tree(Control).gtk_button_press_event(long, long) line: 3012 Tree(Composite).gtk_button_press_event(long, long) line: 726 Tree.gtk_button_press_event(long, long) line: 1827 Tree(Widget).windowProc(long, long, long) line: 1934 Tree(Control).windowProc(long, long, long) line: 5588 Tree.windowProc(long, long, long) line: 3546 Display.windowProc(long, long, long) line: 4685 OS._gtk_main_do_event(long) line: not available [native method] OS.gtk_main_do_event(long) line: 9228 Display.eventProc(long, long) line: 1225 OS._g_main_context_iteration(long, boolean) line: not available [native method] OS.g_main_context_iteration(long, boolean) line: 2407 Display.readAndDispatch() line: 3396 PartRenderingEngine$4.run() line: 1127 Realm.runWithDefault(Realm, Runnable) line: 337 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1018 E4Workbench.createAndRunUI(MApplicationElement) line: 156 Workbench$5.run() line: 654 Realm.runWithDefault(Realm, Runnable) line: 337 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 598 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 150 IDEApplication.start(IApplicationContext) line: 139 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 380 EclipseStarter.run(String[], Runnable) line: 235 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 497 Main.invokeFramework(String[], URL[]) line: 648 Main.basicRun(String[]) line: 603 Main.run(String[]) line: 1465 Main.main(String[]) line: 1438
Created attachment 253710 [details] SWT test snippet Hello, I created a test snippet where there is a SWT Tree and a StyledText. When double-clicking on the tree, I change the focus to the StyledText. There is no follow-up "mouse up" event comming from SWT Tree after a double click, only a mouse up event. Focus is not lost. Based on the above, I'm not sure if this is an issue in SWT or somewhere higher up in JFace/PlatformUI. An SWT snippet would greatly help.
Created attachment 253711 [details] treeSelectionIssue.java Hello, I worked on this some more, testing with selectionEvents. I modified the snippet and attached it. It may be reproducing the issue at hand, but I would like to clarify. In regards to what you said: > It seems that the SWT Tree widget fires a DefaultSelection event, which > Eclipse uses to open the file... but then it fires a MouseDown which causes > keyboard focus to move back to the Package Explorer. Seems like an event order > issue. Since the MouseDown caused the selection change, I would expect the > MouseDown event to arrive prior to the selection change. The actual order of events when double clicking in Tree, with mouse and selection listeners is as following: Tree Mouse down Tree Selection Tree Mouse up. Tree Mouse down. Tree Default selection <<<< occurs on double click. Tree Mouse double click <<< observe, "double click after mouse down". Tree Mouse up. If the Text.SetFocus() method is put into default-selection instead of double-click, then indeed the Text does not receive focus as the mouse-double-click steals it away. SWT Tree does not fire a mouse-down after a default-selection-event. However, it does fire a Mouse-double-Click event after a default-selection-event. From the above, it seems you say "MouseDown" but you actually mean "Mouse Double Click". Is this correct? If this is the case, am I correct to understand that you would prefer the order of events to be so that double-click is sent before default-selection, like so:? Tree Mouse down Tree Selection Tree Mouse up. Tree Mouse down. Tree Mouse double click Tree Default selection << default selection to be triggered after double click? Tree Mouse up. Please let me know and if it is so, then I could look into the root cause of the issue.
Re: Comment 2 What you say sounds plausible. It seems like I may have seen the double-click event and mistaken it for a mousedown. I haven't had time to cycle back to this one yet, but I'm currently working on an SWT logging tool that will help with this class of bug. Should be ready soon, at which point I'll be able to easily compare the event order on windows versus gtk.
New Gerrit change created: https://git.eclipse.org/r/49702
The attached *PREVIEW* patch fixes the issue: https://git.eclipse.org/r/#/c/49702 It does 2 things: 1) Removes old obsolete workaround (see patch for details). 2) Delays DefaultSelection event so that it is the last one to fire. The issue here is that Gtk/Gdk sends us the DefaultSelection event before double-click event is sent & handled. We can't really slow down Gtk/Gdk from sending us events differently. However we can manually post-pone the execution till after Control:gtk_button_press(long,long,bool) has finished. The patch currently uses an async thread sleep. Ideally I need to implement some sort of monitor/lock mechanism. The issue with re-arranging the order of events is that it could become platform (gtk) specific. I do not know the order of events on Cocoa and Win32. @Stefan: > First observed some time in 2010 on GTK. By this, do you mean it doesn't occur on Cocoa and Win32 or that you haven't tested it on the other platforms? If you have access to Win32/Cocoa, would you be able to run the attached snippet and let me know what it prints?
Turns out that this is a duplicate. Work will continue in the bug submitted 5 years ago. *** This bug has been marked as a duplicate of bug 312568 ***
