context menu positioned next to mouse pointer when using keyboard in stead of next to keyboard position (nautilus, gnome menus, ...)

[costales]

In nautilus the key that invokes the right-click context menu not works fine (In Windows works better).
I like use the keyboard only, not the mouse.
I put on an item, and if I press the key that invokes the right-click context menu, the submenu is where is the mouse, and not of nautilus (As Windows with explorer).
Ubuntu 7.10.
Greetings.

[Koen (koen-beek)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in nautilus

[Koen (koen-beek)]

What key invokes the right-click context menu ?

   thanks,

     Koen

[costales (costales)]

Hello.
The contextual menu's key is the left key (In spanish keyboard) of the Control key (His function is the same that one Right Click Mouse).
The last keyboard's row is:
Ctrl Win Alt Space AltGR Win CONTEXTUAL_MENU Ctrl

Example of bug (If you can, do it in Ubuntu and Windows for see the difference):
1.- Open Nautilus/Explorer.
2.- Restore Window
3.- Put the cursor mouse outside this last window.
4.- Navegate in Nautilus/Explorer only with keyboard.
5.- PUSH CONTEXTUAL SUBMENU'S KEY!
6.- In Nautilus the submenu that appear is the correspondent to the over the cursor mouse.
     In Windows the submenu that appear is the correspondent to the over the active item keyboard of Explorer.
(Same in Word, Start menu....)

I believe that failure is Gnome, because in Gnome menus or applications failure too -> If you have the cursor mouse in a point, and press the key, the submenu is associated over the cursor mouse, not where is the cursor keyboard (nautilus, menu gnome, gedit....).
Windows works better this feature. When you're in Explorer or Word, the submenu is relationated to the application, not the cursor mouse.

Greetings.

[Koen (koen-beek)]

Hi,

 thanks for your explanation (I have never used this key on my keyboard before)

 I have the same behavior in nautilus -> context menu pops up next to mouse pointer in stead of cursor -> KO
 however in gedit, the context-menu pops up next to the cursor when using the keyboard -> OK in gedit for me
 I have also tried in the gnome menu -> KO

 confirmed

    Koen

[Koen (koen-beek)]

My version of Ubuntu is 7.10 Gutsy Gibbon 64 bit

version of nautilus : 1:2.20.0-0ubuntu7
version of gnome-menus : 2.20.1-0ubuntu1
version of gedit : 2.20.3-0ubuntu1 (as mentioned gedit seems to work correctly for me : context menu next to cursor when using keyboard)

P.S. My previous attachment is .ogg video

  cheers,

    Koen

[costales (costales)]

Aclaration:
The submenu is the correct for Nautilus, but the coordenate when appears is incorrect.
Regards.

[gwi (george-willegers)]

I would also like to see this fixed. The menu location should logically (IMO) be tied to the object it will act upon (where the focus of the user's attention is), not to the (arbitrary position of the) mouse pointer.
If the context menu is activated by using the right mouse key, both locations are (more or less) the same. If the menu is activated by the menu key, the mouse pointer can be in another location.
Ideally the upper left corner of the menu appears in the center of the bounding box of the related object (e.g. a the text of a listview item, a desktop icon).

[Noel J. Bergman (noeljb)]

After seeing Bug #302620, I just tested the behavior against Gnome 2.24.1 (Jaunty), and the context menu key (shift-F10 for me) works as desired.

[costales (costales)]

In Jaunty, with Gnome 2.24.1, NOT works for me.
The menu appear where the pointer mouse is, not where the action is done.
Best regards.

[gwi (george-willegers)]

In Intrepid, which also has Gnome 2.24.1, it does NOT work as requested. As Marcos reported the menu still appears at the mouse pointer's location, not at the related object's location. And this is the same for the context menu key and for shift-F10.

[Noel J. Bergman (noeljb)]

OK, I have tested this on both Intrepid and Jaunty. Have not yet gone back to Hardy. Tested as follows:

 1) Select a .tgz.
 2) Right-click on the archive to verify that Open With "Archive Manager" is present
 3) Click on a PDF file.
 4) Move the mouse back to hover over the the .tgz and hit Shift-F10
 5) Verify that the context menu is for the selected PDF, including "Open With Adobe Reader 8"

This is the desired behaviour [sic], correct?

 gnome-menus 2.24.1-0ubuntu1
 nautilus 1:2.24.1-0ubuntu1

So ... any ideas on what to look at for the difference?

[costales (costales)]

The bug is the location context menu, not the context menu.
Please, use only the keyboard ;) and the mouse pointer more far ;)

[Noel J. Bergman (noeljb)]

And now I've gone back and tested on Hardy, as well.

gnome-menus 2.22.2-0ubuntu1
nautilus 1:2.22.5.1-0ubuntu1

The context menu appears for the object selected, not the object over which the mouse hovers.

[costales (costales)]

Hi!
Watch this video ;)
http://download283.mediafire.com/dvgwodg15mgg/ymnmzm2oxli/out.ogg.ogv
I put the mouse far of nautilus window.
Then I use only the keyboard, I select "About Ubuntu" and press Shift-F10 -> THEN THE MENU APPEAR in a wrong position ;)

[Noel J. Bergman (noeljb)]

> The bug is the location context menu, not the context menu.

Thanks for the recordmydesktop demo.

So it is not about the content of the menu, but about where the menu appears on the screen. And, yes, now that I understand the complaint, I am able to reproduce the objectionable behavior.

Do we know where in the code the location of the pop-up menu is determined? And is the position of the selected item available in that context?

[costales (costales)]

Hi! :)
I don't know about the code or where is the problem (gnome, mouse,...). Sorry.

[dobey (dobey)]

This definitely has nothing to do with the gnome-common package. I think it is a general gtk+ issue though, so am moving to the gtk+ package. It seems like gtk+ should be positioning near the focus instead of the mouse, which it is doing now. All the key does is cause a right-click event to be simulated, and is not treated specially different from a right click, which is presumably why the behavior is the current way.

[Sebastien Bacher (seb128)]

the bug should be sent to bugzilla.gnome.org where the people writting gtk will read it too

[gwi (george-willegers)]

Just reported the bug: http://bugzilla.gnome.org/show_bug.cgi?id=579872

[Pedro Villavicencio (pedro)]

Thanks for sent it upstream.