Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 319671

Summary:	Tree selection in Cocoa jumps to another item when the dialog resizes
Product:	[Eclipse Project] Platform	Reporter:	Anirudh Sasikumar <anirudhsasikumar>
Component:	SWT	Assignee:	Scott Kovatch <skovatch>
Status:	RESOLVED FIXED	QA Contact:	Silenio Quarti <Silenio_Quarti>
Severity:	normal
Priority:	P3	CC:	mayankk, mschrag, pinnamur, rvonmassow, Silenio_Quarti, skovatch
Version:	3.6
Target Milestone:	4.3 M4
Hardware:	Macintosh
OS:	Mac OS X
Whiteboard:

Description Anirudh Sasikumar

2010-07-13 04:52:53 EDT

Build Identifier: 20100617-1415

A click on a tree item where:

1. The mouse button is not released very fast and 
2. Dialog resizes 

causes selection to jump.

This bug affects Adobe Flash Builder in the project properties dialog.

This is reproducible in Eclipse's project properties dialog and Eclipse's Preference page.

Setting a breakpoint in Tree's sendSelection() with hit count 2 will give the stack trace of the problem: Tree.sendSelection() determines a different row number than Tree.mouseDownSuper().

Note: This bug is more prevalent when using the older generation Apple mouse since button responsiveness is poorer compared to the current generation mouse.

Reproducible: Always

Steps to Reproduce:
1. In Eclipse Java Perspective, right click on a Java project and go to Project properties.
2. Ensure selection is in a page like "Resource" or "WikiText". If not, select "Resource" and hit cancel and open the dialog again.
3. Click on "Java Compiler" while ensuring that the mouse button is not released quickly.

Selection will now jump to "Task Tags"

Comment 1 Scott Kovatch

2010-07-22 20:53:03 EDT

This happens because we are sending a selection event during the outlineViewSelectionIsChanging notification. The dialog resizes and then the NSOutlineView continues to track the mouse. My guess is that the enlargement of the dialog makes the outline view think a different row was clicked, hence the selection changing notification.

Silenio, why are we listening to both the selectionIsChanging and selectionChanged events? Carbon only sent a selection event when the click finished. I haven't tried Windows to see if this is a consistency thing.

If I comment out the code in outlineViewSelectionIsChanging this bug goes away, but I want to check before I change that.

Comment 2 Scott Kovatch

2010-07-30 12:51:59 EDT

(In reply to comment #1)
> Silenio, why are we listening to both the selectionIsChanging and
> selectionChanged events? Carbon only sent a selection event when the click
> finished. I haven't tried Windows to see if this is a consistency thing.

Answering my own question... This is because you can drag-select in an NSOutlineView/NSTableView. Every time you move over an item you get an outlineViewSelectionIsChanging event. Reacting to that event isn't necessarily normal/expected behavior. See Xcode's help window, for example. It would be nice if we could make that configurable.

Comment 3 Silenio Quarti

2010-08-04 12:23:33 EDT

We listen for selectionIsChanging to have the same ordering of events of the other platforms (SWT.MouseDown, SWT.Selection, SWT.MouseUp). The selectionChanged event comes after mouse up on cocoa.

Comment 4 Scott Kovatch

2011-01-06 14:47:46 EST

I'm no longer seeing this bug on I20101208-1300. I know that mouse event generation changed in this area, but I'm not sure exactly what fix did it.

Comment 5 Robert von Massow

2012-12-11 07:43:45 EST

To be honest, I think this problem still exists. In our framework we build a toolbar according to the selection in a tree below the toolbar. The visual design may in some cases cause a line wrap in the toolbar (I didn't do the GUI design and I'm not a fan of that). If the line wraps and the tree is moved down by the line wrap, another node will be selected. The selection of the other node causes the toolbar to be rebuilt again. Currently I work around the problem by registering a filter on the SWT display and drop the second selection event and then adjusting the selection in the tree in turn (the wrong item will be marked selected otherwise). This is a really dirty hack but was the only solution I could come up with.