Moving diagonally from narrow menu title often opens adjacent menu

Bug #552920 reported by Bálint Magyar on 2010-03-31
162
This bug affects 26 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Low
Unassigned
Unity
Medium
Unassigned
gtk+2.0 (Ubuntu)
Low
Unassigned
gtk+3.0 (Ubuntu)
Low
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

gtk 2.22, Ubuntu 10.10

1. Click on the volume control to open the sound menu.
2. Move the pointer diagonally to click on the maximum volume button.
<https://launchpadlibrarian.net/42732636/Why_autoexpanding_indicators_are_a_bad_idea.png>

What often happens: The sound menu closes, and the menu next to it opens.
Screencast: <https://www.youtube.com/watch?v=lVUokjAlREs>
Example in an informal usability test: <https://www.youtube.com/watch?feature=player_detailpage&v=PgGbZfR6Vec#t=13m55s>

What should happen: The sound menu stays open.

One solution would be to make the volume slider vertical. But this would not work for other menus (like the Bluetooth menu), and would look awkward with other items in the menu.

Another solution would be to use a timer for closing the current menu and opening a new one. This is what Windows does for submenus. But it has the drawback of slowing down browsing, which would be worse for top-level menus than for submenus.

GTK already has a more sophisticated solution for submenus, similar to Mac OS: a triangle based on the corners of the submenu and its parent item, in which there is a much longer delay for closing the submenu and changing the menu selection. <http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/HierarchicalMenus.html>
Discussion of the invisible triangle for submenus in GTK:
<http://mail.gnome.org/archives/gtk-devel-list/2000-May/msg00118.html>

However, this feature in Gtk+ has been broken since July 2013. <https://bugzilla.gnome.org/show_bug.cgi?id=710388> The code, once fixed, should be applied to menu titles as well.

More information: <http://thomaspark.co/2011/10/making-menus-escapable/>

Bálint Magyar (balintm) wrote :
Sense Egbert Hofstede (sense) wrote :

Thank you for helping with making Ubuntu better by reporting this bug. We've briefly discussed this issue on IRC and decided that this issue deserves some more attention. I'm marking this bug as Triaged and am opening an task in the upstream project so we can keep track of it there as well.

description: updated
Changed in indicator-application (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in indicator-application:
status: New → Confirmed
summary: - Autoexpanding indicator menus hurt usability
+ Auto-expanding AppIndicator menus makes navigating to menu items harder

I'm going to switch this to a GTK+ bug. Really GTK+ should handle this, we're just using shorter menu titles than it's used to so I don't think anyone has noticed before.

Changed in indicator-application:
status: Confirmed → Invalid
affects: indicator-application (Ubuntu) → gtk+2.0 (Ubuntu)
Changed in gtk+2.0 (Ubuntu):
assignee: nobody → Cody Russell (bratsche)
description: updated
summary: - Auto-expanding AppIndicator menus makes navigating to menu items harder
+ Moving diagonally from narrow menu title often opens adjacent menu
Vish (vish) wrote :

Ha! i was searching for this bug a couple of days ago.. when i should have been watching my inbox instead.. [thanks mpt. ;-) ]

affects: indicator-application → hundredpapercuts
Changed in hundredpapercuts:
status: Invalid → New
importance: Undecided → Low
milestone: none → nt7-potpourri
status: New → Triaged
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Carl Simpson (cwd-simpson) wrote :

It might be worth considering (if it's even possible) only having a timer on menu opening if the mouse is actually moving diagonally. That way might keep the responsive feel when moving from menu to menu whilst stopping the reported behaviour.

Paul Sladen (sladen) wrote :

This problem has been solved repeatedly time-and-again since the mid-1980s. The solution is a triangular bounding box and should be something that the standard GtkMenu/Qt menu widget should be doing automatically. If the indicator widgets were switched to be standard GtkMenu/Qt widgets then this should be solved immediately (as would the issues of keyboard interaction and scrubbing).

Matthew Paul Thomas (mpt) wrote :

The indicator menus are standard GTK menus, which is why this bug is filed against GTK. GTK menu titles have never had the same diagonal forgiveness that submenus have had.

Paul Sladen (sladen) wrote :

mpt: thanks for the clarification; so it's more that the *existing* sub-menu code should also be applied to the top-level menus (for Gtk+).

description: updated
Changed in gtk+3.0 (Ubuntu):
status: New → Confirmed
Omer Akram (om26er) wrote :

unasigned brastche as he is not on the project anymore.

Changed in unity:
importance: Undecided → Medium
status: New → Triaged
Changed in gtk+2.0 (Ubuntu):
assignee: Cody Russell (bratsche) → nobody
Changed in gtk+3.0 (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Didier Roche (didrocks) on 2011-09-30
Changed in unity (Ubuntu):
status: New → Triaged
Omer Akram (om26er) on 2012-02-09
Changed in unity (Ubuntu):
importance: Undecided → Medium
Chris Wilson (notgary) on 2012-11-28
Changed in hundredpapercuts:
milestone: nt7-potpourri → raring-gtk
description: updated
Rafael Belmonte (eaglescreen) wrote :

Why don't you take a look at how GNOME-SHELL avoids this unpleasant behavior?

Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers