Volume slider in sound indicator ignores the "volume" action coming from indicator-sound in a particular case
Bug #1520548 reported by
Xavi Garcia
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical System Image |
Fix Released
|
Medium
|
kevin gunn | ||
| unity8 (Ubuntu) |
Fix Released
|
Medium
|
Nick Dedekind | ||
Bug Description
To re-create this:
Use last rc flash image.
1. Plug headphones in
2. Play audio multimedia
3. Open the sound indicator
4. Move the volume slider to the maximum
A warning dialog should appear asking the user to approve high volume
At this point the indicator-sound has clamped the volume to 75% waiting for the user to accept or decline the warning.
5. Press cancel
6. The slider shows the value over 75%
I can see with dbus-monitor that the volume action signal is emitted with the 75% value, although it seems that the UI is ignoring it.
Related branches
lp:~xavi-garcia-mena/indicator-sound/action-sync-volume
- Nick Dedekind (community): Approve
- Charles Kerr (community): Approve
- PS Jenkins bot (community): Approve (continuous-integration)
-
Diff: 627 lines (+307/-25)13 files modifiedsrc/service.vala (+30/-9)
src/sound-menu.vala (+7/-4)
src/volume-control-pulse.vala (+20/-0)
src/volume-control.vala (+7/-0)
tests/CMakeLists.txt (+2/-2)
tests/dbus-types/CMakeLists.txt (+3/-1)
tests/dbus-types/dbus-action-result.cpp (+93/-0)
tests/dbus-types/dbus-action-result.h (+50/-0)
tests/dbus-types/dbus-types.h (+2/-0)
tests/dbus-types/org.gtk.Actions.xml (+5/-0)
tests/integration/indicator-sound-test-base.cpp (+66/-0)
tests/integration/indicator-sound-test-base.h (+6/-0)
tests/integration/test-indicator.cpp (+16/-9)
lp:~nick-dedekind/unity8/lp1520548.volume-resync
- Albert Astals Cid (community): Approve
- PS Jenkins bot (community): Needs Fixing (continuous-integration)
-
Diff: 33 lines (+13/-1)1 file modifiedqml/Panel/Indicators/MenuItemFactory.qml (+13/-1)
| Changed in unity8 (Ubuntu): | |
| assignee: | nobody → Nick Dedekind (nick-dedekind) |
Revision history for this message
| Nick Dedekind (nick-dedekind) wrote | #1 |
Revision history for this message
| Xavi Garcia (xavi-garcia-mena) wrote | #2 |
| Changed in unity8 (Ubuntu): | |
| status: | New → In Progress |
| importance: | Undecided → Medium |
| Changed in canonical-devices-system-image: | |
| status: | New → Fix Committed |
| importance: | Undecided → Medium |
| assignee: | nobody → kevin gunn (kgunn72) |
| milestone: | none → ww02-2016 |
Revision history for this message
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in unity8 (Ubuntu): | |
| status: | In Progress → Fix Released |
| Changed in canonical-devices-system-image: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
The UI is stuck in a "waiting for server" state. We are using a live slider, and constantly sending updates to the server. And since the server stops responding to our requests (doesn't set the value to above 75% until we let it) we stick in this state for a timeout (up to 30 seconds), after which we will reset to the server state.
So we do eventually end up in the correct value, but it takes time.
This is because if we responded directly to every server change, the UI would be unusable (slider would bob/stutter about as we drag it). We can't do much about the server silently rejecting change requests other than re-syncing the server value after a time.
That being said, I've had a bit of a thought.
We basically need some feedback from the server to cause a "reset to server value". Could we add an action to the backend for this? Think of it like a "in-sync number". If we detect an increment to the sync number, we re-sync to the server value. The backend could increment the action value after the user decision on the snap decision.