This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 110563 [details] Proposed changes to MouseUtils.java During fixing issue #201572 it turned out, that SwingUtilities.isRight/MiddleMouseButton give incorrect results if some of the modal keys (alt, meta) are pressed. This is because mouse button bits in the event object have the same numeric value as some of those modal keys. So ALT+left click causes isMiddleMouseButton to return true, META-left click causes isRightMouseButton to return true. Our MouseUtils currently contain deprecated methods for testing mouse buttons, they're deprecated because offer no advantage over standard Swing. I recommend to either: a/ UNdeprecate isRightMouseButton + add isMiddleMouseButton, as shown in the attached diff. b/ provide additional methods (isXXXMouseTrigger) isLeftMouseButton operation is not obscured, it does not need to be un-deprecated (added), although I believe that for API consistency the method should be present (undeprecated) in MouseUtils (method is changed in the diff). As for implementation: note the difference between getModifiers() and getModifiersEx(). While getModifiers() return bitmask of keys(buttons) that triggered the event, getModifiersEx() return bitmask of state JUST AFTER the event. In the case of a mouse-click, the MOUSE_DOWN_MASK for the clicked button is already gone (button released), so JDK 1.4 getButton() must be used to test origin of the event. While on the topic, I noticed that most of the code checks for mouse clicks, but with no provisions for other modal keys (ctrl/alt/...). While for most places this is probably OK, it is a bug for text editing features, where modifiers may come to play from configured shortcuts. A convenient isXXXMouseClicked(MouseEvent, int requiredKeys) could be helpful to promote proper checking (getModifiersEx() & MODAL_KEY_MASK == requiredKeys) Not a strictly required API/util method, so not included in the diff. Please decide whether it should be included.
By the way do not use the IDE's "Export Diff" action to prepare diffs for review (or really any other purpose); use hg diff --git or the equivalent: http://wiki.netbeans.org/HgHowTos#Develop_API_review_patches_using_MQ (In reply to comment #0) > it turned out, that > SwingUtilities.isRight/MiddleMouseButton give incorrect results if some of the > modal keys (alt, meta) are pressed. Is this filed upstream in the JRE? If not, do so now. Include jdk_bug_nnnnnnn in the Status Whiteboard field for tracking. We would generally not want to have methods duplicating standard functionality in the JRE, especially functionality that could be platform- or L&F-specific (did you check behavior on a Mac?), particularly when the implementation is as trivial as 'e.getButton() == MouseEvent.BUTTON3'. Or I would at least wait for evaluation of the JRE bug. > As for implementation: note the difference between getModifiers() and > getModifiersEx(). Nothing of the sort is mentioned in the patch; what impl are you referring to?
re. impl note - the JRE implementation uses getModifiers() to determine pressed button. There's also getModifiersEx() with different bitfield values which represent buttons + modifier combinations correctly, but also different behaviour from the old getModifier(). That method cannot be used to produce the result similar to getModifier() - a different way must be used to get +- same behaviour as the original isXXXMouseButton(). Will wait for JRE defect evaluation
please reopen if the jdk bug is rejected, thanks
Note - the defect is reported to be fixed in JDK: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088744
*** Bug 226772 has been marked as a duplicate of this bug. ***