Community
Participate
Working Groups
1. Open the Java perspective, or any other perspective where there's a view on the left (e.g. Package Exlorer), and no open views to the right of it. 2. Click once within the view on the left. 3. In the empty space to the right, quickly right-click then left-click. 4. This registers as a double-click within the view on the left. The vertical position of the registered double-click will be the same as the vertical position of the mouse. -- Configuration Details -- Product: Eclipse 1.3.0.20100609-1425 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.platform 3.6.0.v20100602-9gF78GpqFt6trOGhL5t0nJy5fyGHKrwNY
I can't reproduce this. But it looks like SWT bug. Assigning to SWT for comments.
I can reproduce this on the 3.6 GM candidate. That's a cool bug! I'll take it.
Thanks...my habit of randomly clicking everywhere sometimes pays off. :) Speaking of which, #316963 seems similar -- maybe they're related.
They likely have the same root cause -- we don't check the buttonMask to see if the first and second events of a click came from the same button, though it's odd that NSEvent.clickCount() doesn't reset if a different button was pressed the first time.
Created attachment 180716 [details] Fix Carbon apparently had this bug as well. The button count doesn't reset if the button clicked doesn't change. It was fixed by tracking the last button clicked.
Double-clicks in general have idiosyncrasies right now in Cocoa, and this fix addresses those, along with bug 316963. We were send the MouseDoubleClick event on the second mouse down, which is inconsistent with the rest of Mac OS X. This change moves the double-click event so it is sent just before the second mouse up in a double-click sequence. That way, if you start a double-click but hold down the mouse on the second click you won't get a double-click if released after the double-click delay. This is, BTW, the true fix for bug 313208.
Fixed > 20101012.
