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.
Maybe it's just me... When I'm looking at code, I may see a method that I want to invoke the context menu on. For example, I right click, and choose "Find Usages". Unwittingly, I didn't notice that the cursor was blinking on some other method, so my results are related to the other method. I make this mistake all the time. To get proper results I must first left click, to move the cursor, then right click to use the context menu on the intended scope. I *think* it would be better if either the cursor moved in response to the context menu trigger (right click), or at least the context menu would be scoped from the current mouse position.
It's probably one of those little peculiarities of java on Mac OS X, because it's working just as you describe (it moves the caret) on my Ubuntu box. Maxi, Jirko or somebody with Mac OS X could you please try to reproduce this? And if reproducible, please turn the issue to a defect. Thanks Product Version: NetBeans IDE Dev (Build 080929) Java: 1.5.0_12; Java HotSpot(TM) Client VM 1.5.0_12-b04 System: Linux version 2.6.22-15-generic running on i386; UTF-8; en_US (nb)
I cannot reproduce it on MacOS 10.4, JDK 1.5.0_13 but there may by difference in JDK 1.6
Well now I can't reproduce it either. I'll try to pay closer attention to the situation if/when it happens again. (Sorry for the false alarm.) FYI, I'm using Java 1.5.0_16-b06-284, on Mac OS X 10.5.5
I finally figured it out! The problem occurs when I have a some text selected. For example, if I double-click a method name (highlighting it), then right-click on a *different* method name to launch Find Usages, the context is the highlighted method instead of the method under the mouse pointer. The root cause may be the fact that the caret does not move when right-clicking while some text is selected. When no text is selected the caret moves as expected. Maybe the status should be change to "defect"?
I see. Once there is a selection the context menu invoked anywhere inside the selection should retain the selection and invoke an action. If caret is outside of the selection then IMO we could possibly deselect first and behave like for no selection. Adding UI guys to cc if they want to comment on this.
I see. Well, the editor can't blindly move the caret when there is selected text, because typically a user wants to perform an action from the popup menu *on* the selected text. But I agree that if you click in some totally different area you are unlikely to want to run an action on the selected text. So, maybe the right-click handler should check where exactly the click happened and either keep the selection (if clicked inside the selected text) or move the caret and thus deselect the text (if clicked outside the selected text).
Just 5 cents from the "UI guy" :).. the current context should take precedence over previously selected text, i.e. the right click should really work on the identifier under the mouse pointer. So, I'm turning this into a defect. I'm not sure about the priority, feel free to decrease it if you don't think it's a P3. The separate question is whether the right-click should force to "forget" the current selection and move the caret. Unless we'll come up with a real-life use-case when this is not desirable (can't think of any right now), I slightly incline towards doing so, but no strong opinion here. Changing platform to "all", reproducible on Mac OS X and Windows Vista.
I found openoffice deselect text on right click outside of selection, but gedit do not deselect and moreover if I paste from clipboard gedit will replace the selection regardless place of context menu invocation(inside or outside of selection). Firefox works the same way as gedit but even paste replace selection, spell check works for word under mouse pointer.
Correction: processFocusEvent is called, but never passed one with id FOCUS_LOST
The following describes the expected behavior on the Windows platform. I'm not familiar with other platforms to give the details for them. Right button down: 1a) Determines the source for the context action. 1b) Processed like left button down (click count 1, no modifiers) for the purpose of assigning focus and selection in the IDE. The only difference between the two is buttons are not moved to the Pressed state in response to the right button down. Things which should change when the click occurs over their relevant controls are the caret position, the selected editor tab, the selected node within the Projects, Files, or Navigator window, etc. Right button move: 2a) No state changes. Right button up: 3a) Displays the context menu for the item determined in when processing the "down" event. 3b) The menu is displayed at the location on screen where the "up" event occurs. --------------------------------- The following describes the observed behavior in 7.1 daily builds: 1a) Not correct. Currently the right button down event determines the context pane (editor, projects, editor tab well, etc), but does not select a specific item within that pane. 1b) Not correct. Focus is assigned to the pane which contains the point, but the selection is not adjusted accordingly. 2a) Appears to work correctly. 3a) Not correct. Currently the right button up event is being used to determine the item for which a context menu is requested. The right button up event should not result in any change of focus, selection, or context item in the IDE. 3b) Correct. The menu is being drawn at the location where the right button is released.
(In reply to comment #0) > Maybe it's just me... When I'm looking at code, I may see a method that I want > to invoke the context menu on. For example, I right click, and choose "Find > Usages". Unwittingly, I didn't notice that the cursor was blinking on some > other method, ... some other method it is the previous search result.
Actually a duplicate filed and fixed as issue #205150 *** This bug has been marked as a duplicate of bug 205150 ***