Bug 258727 - CTabFolder should not select an item unless the first button has been pressed
Summary: CTabFolder should not select an item unless the first button has been pressed
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.5 M6   Edit
Assignee: Felipe Heidrich CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 60833 258511
  Show dependency tree
 
Reported: 2008-12-13 02:17 EST by Remy Suen CLA
Modified: 2009-01-30 16:22 EST (History)
4 users (show)

See Also:

Attachments
Patch to potentially implement the feature request. (1.03 KB, patch)
2008-12-13 02:19 EST, Remy Suen CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Remy Suen CLA 2008-12-13 02:17:38 EST 
In CTabFolder's onMouse(Event) handling of the SWT.MouseDown event, there is a fair amount of conditional blocks that prevents things from happening unless the first mouse button is the one that was clicked. This is not in place for tab selection. There are requests against platform to not select a part when the user right-clicks on it (bug 60833) and to close it when it's been middle-clicked (bug 258511). This behaviour can be observed on applications like Firefox and IE7. If I invoke Ctrl+H and bring up the search dialog, I can see that right-clicking and middle-clicking doesn't cause the tabs to switch. Can the same be implemented for CTabFolder?
Comment 1 Remy Suen CLA 2008-12-13 02:19:41 EST 
Created attachment 120388 [details]
Patch to potentially implement the feature request.

I'm not familiar with SWT's code at all but I hope this patch will at least help illustrate what I'm requesting here.
Comment 2 Remy Suen CLA 2009-01-19 09:07:43 EST 
Can anybody from SWT comment on this? I presume this probably won't make it into 3.5 because everyone's busy with the Cocoa port but is there any hope of getting it committed in the future or would this change in behaviour be considered a contract breach of some sorts?
Comment 3 Felipe Heidrich CLA 2009-01-19 15:56:22 EST 
I just checked the code (handling of mouse down for CTabFolder) and it was written carefully to change item selection when any button is pressed. I can actually switch tab using the back and foward button on my mouse.


Steve: do you know why it was implemented like that ?
Comment 4 Steve Northover CLA 2009-01-21 14:45:47 EST 
> Steve: do you know why it was implemented like that ?

Nope.  You could ask Veronika.
Comment 5 Felipe Heidrich CLA 2009-01-27 17:32:32 EST 
(In reply to comment #4)
> > Steve: do you know why it was implemented like that ?
> Nope.  You could ask Veronika.

I checked the CVS history and it seems that this any-button-goes behaviour is by design only (no technical reason for it). The last time we changed the code in this area was back in Feb/2004b (version 1.86->1.87) the comment was 'Cut over to new look'.

Veronika, do you know of any reason why we shouldn't change this ?
Comment 6 Steve Northover CLA 2009-01-27 19:32:41 EST 
I think we should just fix this.  Can you think of any reason it was coded this way?  Is it so that when a menu is popped up, the tab is switched and the context for the menu is right?
Comment 7 Steve Northover CLA 2009-01-27 19:33:23 EST 
FH, fix it or close the bug.
Comment 8 Felipe Heidrich CLA 2009-01-30 16:22:31 EST 
Fixed in HEAD > 20090130

CTabFolder is fixed, you can verify it using CustomControlExample.
Eclipse still has the problem, UI must have its own implemenation to handle mouse events.