Inconsistent behavior of slider widgets

Bug #953757 reported by Lars Karlitski on 2012-03-13
34
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Undecided
Matthew Paul Thomas
GTK+
Fix Released
Medium
Indicator Display Objects
Fix Released
Undecided
Lars Karlitski
gnome-control-center (Ubuntu)
Medium
Unassigned
ido (Ubuntu)
Undecided
Lars Karlitski
rhythmbox (Ubuntu)
Medium
Unassigned
totem (Ubuntu)
Medium
Unassigned

Bug Description

In gtk+, left-clicking on any point inside the bar of a slider widget moves the thumb one step towards that point. The thumb can be moved to a specific point directly by middle-clicking that point on the bar.

In Ubuntu, some slider widgets have been altered to always jump to the clicked point directly, regardless of the mouse button that was pressed.

This is inconsistent and confusing, especially when sliders in the same app behave differently. For example, the mouse, keyboard, brightness, and accessibility settings in System Settings use the gtk+ style slider, while the sound and appearance settings use the other style.

Furthermore, this kind of change should not be made inside applications, but in gtk+ itself (even if the two kinds of behaviors are desired).

Assigning to Christian Giordano, as he's the bug contact on bug #898611, which made me aware of this issue.

Related branches

Lars Karlitski (larsu) wrote :

I can't add ayatana-design as being affected by this bug. Can someone with the appropriate rights please do this for me?

Changed in gtk+3.0 (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
Charles Kerr (charlesk) wrote :

The flipside to this consistency issue is that many users reported accidentally turning their volumes up to 0% or 100% by using the standard GTK+ slider behavior when one left-click-and-holds. If you click at the midpoint mark in a volume slider, you probably aren't expecting the volume to keep moving past 50% to either 0% or 100%...

Matthew Paul Thomas (mpt) wrote :

There are three possible behaviors here, when you press down in a slider trough between the thumb and one end.

(1) Move in steps towards that end, up to and right past the pointer, stopping at the end. This is what upstream GTK does.

(2) Move in steps towards that end, but only up to where the pointer is, and stop there. This is what Windows does (tested in Windows 7).

(3) Move the thumb immediately to where the pointer is, and allow dragging. This is what Mac OS X does (tested in 10.8 preview).

I don't know of anyone who thinks that (1) is a good idea, and it causes the accidental silence/blaring that Charles describes. But Lars is right, it shouldn't be changed piecemeal, it should be changed in GTK for every slider.

The advantage of (2) are that it's consistent with how standard scrollbars behave. (OS X has a setting for whether scrollbars should do the equivalent of (2) or (3), but (2) is the default, and scrollbars are hidden by default anyway.)

The advantages of (3) are that it's consistent with how scrub bars behave, such as in a music or movie player (though there are many fewer scrub bars than scrollbars); and that it allows immediate dragging to fine-tune the setting, without first having to release and re-click.

I prefer (2), though not strongly -- I'd be happy with either (2) or (3).

Matthew Paul Thomas (mpt) wrote :

So, let's try implementing (2) in GTK, and removing the custom code from the Sound and Appearance panels and IDO.

Changed in ayatana-design:
assignee: nobody → Matthew Paul Thomas (mpt)
status: New → Fix Committed
Christian Giordano (nuthinking) wrote :

I agree that option 1 is definitely the worst. I am inclined to option 3 simply because it is a standard behavior on the web (and in many other places, even GNOME uses it in the sound menu!). It is also more touch friendly.
I don't think sliders and scrollbars should necessary be so consistent (two very different beasts), but, as mpt says, our scrollbars are hidden anyways.

I discussed the matter with the people in GNOME and they actually deliberated for option 3 for sliders and also scrollbars (preserving the consistency). Clearly, I am not sure about the latter choice, but this is what our patch should do to get accepted. As said few times, this doesn't affect us.

Lars Karlitski (larsu) on 2012-03-14
Changed in ido:
assignee: nobody → Lars Uebernickel (larsu)
Changed in gnome-control-center (Ubuntu):
assignee: nobody → Lars Uebernickel (larsu)
Changed in gtk+3.0 (Ubuntu):
assignee: nobody → Lars Uebernickel (larsu)
Changed in ido (Ubuntu):
assignee: nobody → Lars Uebernickel (larsu)
Matthew Paul Thomas (mpt) wrote :

If by "deliberated for option 3" you mean "decided on option 3", then great, let's submit it upstream if it's not done already. One less patch to carry in the long run, and simpler code in three other places.

Christian Giordano (nuthinking) wrote :

@mpt, yep. That's what I meant. In italy we use that verb for new laws or court outcome. Evidently in English is not! ;)

Lars Karlitski (larsu) wrote :

Could we please get a feature freeze exception for this in gtk3?

This would unify slider behavior again and we could get rid of the ugly "act-as-if-middle-button-was-pressed" hacks in IDO and gnome-control-center.

I've submitted the patch upstream at https://bugzilla.gnome.org/show_bug.cgi?id=563688. GNOME designers support the change, so it has good chances of being accepted.

The package with my patch builds and works as expected. I've been running it for a bit on my system and tested every slider I could find, in particular all default applications.

Changed in gtk+3.0 (Ubuntu):
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

UIF -wise this seems fine for me, consistency is always good, and almost a bug fix anyway. Approved.

Changed in ido (Ubuntu):
status: New → Confirmed
Changed in gnome-control-center (Ubuntu):
status: New → Confirmed

@pitti yay! :)

Lars Karlitski (larsu) on 2012-03-16
Changed in gnome-control-center (Ubuntu):
status: Confirmed → In Progress
Changed in ido:
status: New → In Progress
Changed in gtk:
importance: Unknown → Medium
status: Unknown → In Progress
John Lea (johnlea) on 2012-03-22
tags: added: udp
Changed in gtk:
status: In Progress → Fix Released
Sebastien Bacher (seb128) wrote :

gtk 3.5 fixes the toolkit side of the issue, we just need to drop the hacks in quantal and that will be sorted

affects: gtk+3.0 (Ubuntu) → ubuntu
Changed in ubuntu:
status: In Progress → Fix Released
Omer Akram (om26er) on 2012-08-09
affects: ubuntu → rhythmbox (Ubuntu)
Changed in rhythmbox (Ubuntu):
assignee: Lars Uebernickel (larsu) → nobody
importance: Low → Medium
status: Fix Released → Triaged
Changed in totem (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in gnome-control-center (Ubuntu):
assignee: Lars Uebernickel (larsu) → nobody
importance: Undecided → Medium
status: In Progress → Triaged
Iain Lane (laney) wrote :

totem and rb are both fixed upstream. I don't know about the others.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:3.4.2-0ubuntu11

---------------
gnome-control-center (1:3.4.2-0ubuntu11) quantal; urgency=low

  * debian/control.in:
    - updated clutter requirement to match the configure version
  * debian/patches/96_sound_nua_panel.patch:
    - drop hacks and merge upstream changes for mouse scrolling (lp: #953757)
  * debian/patches/git_sound_sliders.patch:
    - "sound: Fix mouse scrolls on sliders"
  * debian/patches/git_update_keyring_password.patch
  * debian/source_gnome-control-center.py:
    - updated for python3, thanks Edward Donovan (lp: #1013171)
  * debian/UbuntuLogo.png:
    - updated logo for 12.10 (lp: #1035501)
 -- Sebastien Bacher <email address hidden> Fri, 24 Aug 2012 18:57:15 +0200

Changed in gnome-control-center (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package totem - 3.4.3-0ubuntu2

---------------
totem (3.4.3-0ubuntu2) quantal; urgency=low

  * debian/patches/git_no_browser_slider_hack.patch,
  * debian/patches/git_no_slider_hack.patch:
    - git patch, drop hack which was breaking "click to jump" behaviour
      with gtk 3.5 (lp: #953757)
  * debian/patches/git_use_keywords.patch:
    - backport upstream patch to set keywords in the desktop entry,
      it makes easier to find totem in the unity dash or gnome-shell
      (lp: #976624)
 -- Sebastien Bacher <email address hidden> Fri, 27 Jul 2012 15:47:52 +0200

Changed in totem (Ubuntu):
status: Triaged → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rhythmbox - 2.97-1ubuntu4

---------------
rhythmbox (2.97-1ubuntu4) quantal; urgency=low

  * debian/patches/git_scale_click.patch: git patch, drop hack which was
    breaking "click to jump" behaviour with gtk 3.5 (lp: #953757)
 -- Sebastien Bacher <email address hidden> Mon, 27 Aug 2012 17:58:13 +0200

Changed in rhythmbox (Ubuntu):
status: Triaged → Fix Released
Lars Karlitski (larsu) on 2012-08-27
Changed in ido:
status: In Progress → Fix Committed
Charles Kerr (charlesk) on 2012-08-28
Changed in ido:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ido - 12.10.1-0ubuntu1

---------------
ido (12.10.1-0ubuntu1) quantal; urgency=low

  * New upstream release:
    - fix inconsistent slider behavior (lp: #953757)
 -- Sebastien Bacher <email address hidden> Tue, 28 Aug 2012 13:49:28 +0200

Changed in ido (Ubuntu):
status: Confirmed → Fix Released
Changed in ayatana-design:
status: Fix Committed → Fix Released
tags: added: reviewedbydesignq
removed: udp
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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.