Mouse release does not activate playback control buttons

Bug #779782 reported by David Tolnay
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ido (Ubuntu)
Low
Unassigned

Bug Description

indicator-sound 0.6.6.1-0ubuntu3, Ubuntu 11.04
indicator-sound 12.10.2+14.04.20140401-0ubuntu1, Ubuntu 14.04

In maverick's sound menu, it was possible to activate the banshee or rhythmbox play/pause, back, and forward controls by pressing the mouse on the indicator applet sound icon, dragging to the chosen control with the mouse button held down, and releasing the mouse button. It looks like the sound menu spec at https://wiki.ubuntu.com/SoundMenu is ambiguous as to whether this should activate the controls, but all other menu items in the indicator applet can be activated in this way (as an example, the mute option in the sound menu). The fact that this no longer works for the playback control buttons seems like a bug.

To be clear, click/release on the sound menu icon followed by click/release on the playback buttons works perfectly well. The inconsistency is in the playback buttons being more picky than other menu items, in that they can't be triggered by just a mouse release.

<https://wiki.ubuntu.com/Sound#playback-item>: "Conversely, clicking on a different menu item (or any menu title), moving to a button, and releasing, should activate that button."

Revision history for this message
David Tolnay (dtolnay) wrote :
Revision history for this message
Conor Curran (cjcurran) wrote :

I don't consider this a bug but more like a bug fix. Play controls or menuitems should not be activated if the proceeding press event occurred in an area outside of the control's space.
The Maverick version was buggy in its handling of key events.

Thanks for reporting this but I feel its a non-starter.

Changed in indicator-sound (Ubuntu):
status: New → Invalid
Revision history for this message
David Tolnay (dtolnay) wrote :

In the past, menuitems have always been activated in this way. They still are (cf. mute option in the sound menu, the applications/places/system menus in GNOME classic, any time you have a context menu). Since that seems to be the precedent, what justifies the playback controls being the single exception?

David Tolnay (dtolnay)
Changed in indicator-sound (Ubuntu):
status: Invalid → New
Revision history for this message
David Tolnay (dtolnay) wrote :

Adding bug #785678 as a duplicate.

Conor Curran (cjcurran)
Changed in indicator-sound:
importance: Undecided → Wishlist
assignee: nobody → Conor Curran (cjcurran)
Robert Roth (evfool)
Changed in indicator-sound (Ubuntu):
status: New → Confirmed
Revision history for this message
Conor Curran (cjcurran) wrote :

I'm not convinced to be honest, awaiting design feedback.

Changed in indicator-sound:
status: New → Incomplete
Changed in ayatana-design:
assignee: nobody → Matthew Paul Thomas (mpt)
importance: Undecided → Medium
John Lea (johnlea)
Changed in ayatana-design:
importance: Medium → Undecided
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

The playback controls aren't the only menu controls that require mousedown as well as mouseup. Just above them is the volume slider, which behaves the same way. And next door, the calendar in the clock menu, which similarly requires mousedown.

For each of those, we could define that they should work on mouseup without mousedown, like menu items do. Would there be any drawbacks?

Changed in ayatana-design:
assignee: Matthew Paul Thomas (mpt) → nobody
Changed in indicator-sound (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
Changed in indicator-sound:
assignee: Conor Curran (cjcurran) → nobody
Revision history for this message
Matthew Paul Thomas (mpt) wrote :
Changed in indicator-sound (Ubuntu):
assignee: Matthew Paul Thomas (mpt) → nobody
importance: Undecided → Low
status: Confirmed → Triaged
no longer affects: ayatana-design
Changed in indicator-sound:
status: Incomplete → Triaged
description: updated
Changed in indicator-sound:
importance: Wishlist → Low
Revision history for this message
Xavi Garcia (xavi-garcia-mena) wrote :

This bug is very very old.

Marking it as invalid to clean up the actual bug list.
If anybody thinks it should be reopened, please feel free to do so

Changed in indicator-sound (Ubuntu):
status: Triaged → Invalid
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Reproduced in indicator-sound 12.10.2+14.04.20140401-0ubuntu1, Ubuntu 14.04.

no longer affects: indicator-sound
Changed in indicator-sound (Ubuntu):
status: Invalid → Triaged
description: updated
Revision history for this message
dobey (dobey) wrote :

Moving to ido where the widget is implemented. The indicator itself doesn't know anything about mouse button press state, menu position or such, as it doesn't render the widgets. That's done on the unity side.

affects: indicator-sound (Ubuntu) → ido (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers