Bugzilla – Full Text Bug Listing
| Summary: | Double-clicking in package explorer leaves focus on package explorer rather than editor | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Stefan Xenos <sxenos> | ||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | lufimtse, yuval.ronen | ||||||
| Version: | 4.5 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| See Also: | https://git.eclipse.org/r/49702 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Stefan Xenos
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 *** |