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.

Bug 148565 - Opening context menu should move cursor or use scope under mouse
Summary: Opening context menu should move cursor or use scope under mouse
Status: RESOLVED DUPLICATE of bug 205150
Alias: None
Product: editor
Classification: Unclassified
Component: Actions/Menu/Toolbar (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Svata Dedic
URL:
Keywords: UI
Depends on:
Blocks:
 
Reported: 2008-09-28 03:00 UTC by janicki
Modified: 2013-07-16 14:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description janicki 2008-09-28 03:00:20 UTC
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.
Comment 1 Vitezslav Stejskal 2008-09-29 08:53:03 UTC
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)
Comment 2 Jiri Prox 2008-09-29 12:16:01 UTC
I cannot reproduce it on MacOS 10.4, JDK 1.5.0_13 but there may by difference in JDK 1.6
Comment 3 janicki 2008-09-29 16:19:10 UTC
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
Comment 4 janicki 2008-10-02 16:35:32 UTC
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"?
Comment 5 Miloslav Metelka 2008-10-03 08:55:45 UTC
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.
Comment 6 Vitezslav Stejskal 2008-10-03 11:27:45 UTC
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).
Comment 7 Ondrej Langr 2008-10-06 12:58:45 UTC
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. 
Comment 8 Sergey Petrov 2009-05-15 10:01:43 UTC
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.
Comment 9 _ tboudreau 2009-08-04 04:23:28 UTC
Correction:  processFocusEvent is called, but never passed one with id FOCUS_LOST
Comment 10 280Z28 2011-10-10 23:52:38 UTC
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.
Comment 11 webcane 2012-06-18 17:59:08 UTC
(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.
Comment 12 Svata Dedic 2013-07-16 14:14:10 UTC
Actually a duplicate filed and fixed as issue #205150

*** This bug has been marked as a duplicate of bug 205150 ***