Newly-sensitive button ignores clicks until cursor re-enters it

Thanks for the bug report. I took your report upstream:
http://bugs.gnome.org/show_bug.cgi?id=317937

Updated upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=56070

*** Bug 28373 has been marked as a duplicate of this bug. ***

https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/30822 is a duplicate which has some test programs and some more details on the problem.

bug #12246 has also a small pygtk example from mvo

Ed Catmur posted a patch in the main report for this bug here: http://bugzilla.gnome.org/show_bug.cgi?id=56070

I'm running the patch on Dapper's gtk+2.0-2.8.18-0ubuntu2 and it works wonderfully. There's a minor change to make it work on 2.8, gtk_window_get_group is called _gtk_window_get_group so I made that change. Modified patch attached.

Any chance this could be included in a Dapper update?

the patch is not trivial and has got no upstream comment nor be used by them yet, so no, it's not a good candidate for a stable upload for now

before you assume this is a problem in gnome... i noticed this behavior in xubuntu 6.06 last week...

John, it's not assumed to be a problem with Gnome. This is a problem with GTK - the toolkit upon which both Gnome and Xfce are built.

Noticed this bug in debian-installer with Feisty Herd-4, with the Forward/Back buttons in the installer wizard. It's quite noticeable.

Regarding the newly edited description:

This isn't limited to behavior after spawed-off dialoges finishes. As I said in my report (one of the duplicates), this also happens when you do a simple search in Synaptic.

although it seems to be a trivial problem, it is quite irritating; it appears in any dialog chain (wizard), where a user repeatedly just wants to click 'OK' or 'Continue'

I notice that the Kubuntu Feisty Fawn installation does not suffer from
the same bug. They have it working properly.

-ray

But the Gnome version of Ubuntu still has the problem. I noticed that when I installed the latest beta (1).

the is an upstream GTK one, nothing Ubuntu specific. The Kubuntu installer is using libqt

I can confirm this bug with every Ubuntu version since Dapper and it is very annoying. I've seen several newbie users who thought they had done something wrong - until they discovered that the button in question "suddenly works", but they don't know why (they have "accidently" moved out of the button and inside again). This bug definately has got some reputation impact, especially since installing Ubuntu means you have to master a ~4 step wizard dialog.

I still notice this in Synaptic under Feisty. It's quite annoying.

This has been happening in Ubuntu since Warty, as far as I know (as I started using Ubuntu since that version).

does this with me as well (from 5.x and newer) wunder if in 7.10 thay fix usablity bugs that have been there for years

thay should thow ubuntu at users to find out how to do simple things that should work and report back and stick help box's there on what to do
not turn into an FAQ hunting day or 2 (an updateable help system be helpfull {internet permitting} or at lest help box's that work and give usefull help on how to fix it)

While guiding a new Ubuntu user (coming from Windows) through the Install process, this was very annoying. Once he clicked the button, he thought it was working so he left it alone until he realized the button didn't actually get clicked. I told him it was a bug and that he needed to move the mouse outside the button and try clicking it again for every step of the install process. The first thing out of his mouth was, "I don't have to do that with Windows". So as trivial as it may seem, this bug affects the usability of the user interface as a whole. Not to mention the fact that the stability of the system comes into question before it even gets installed.

guys, i filed this bug in the summer of 2005!!!!! i've been getting an
email or 2 a week about it ever since!!!! someone fix it already!

thanks :-)

On 7/9/07, Ross Peoples <email address hidden> wrote:
>
> While guiding a new Ubuntu user (coming from Windows) through the
> Install process, this was very annoying. Once he clicked the button, he
> thought it was working so he left it alone until he realized the button
> didn't actually get clicked. I told him it was a bug and that he needed
> to move the mouse outside the button and try clicking it again for every
> step of the install process. The first thing out of his mouth was, "I
> don't have to do that with Windows". So as trivial as it may seem, this
> bug affects the usability of the user interface as a whole. Not to
> mention the fact that the stability of the system comes into question
> before it even gets installed.
>
> --
> Newly-sensitive button ignores clicks until cursor re-enters it
> https://bugs.launchpad.net/bugs/22930
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

This bug is 2 years old ? Do you mean that there's already a fix for this bug ?

i wasnt the first one to file it. so that makes it at least 2 years old.

i'm using the latest version of synaptic and its still not fixed.

On 7/9/07, Mertiki <email address hidden> wrote:
>
> This bug is 2 years old ? Do you mean that there's already a fix for
> this bug ?
>
> --
> Newly-sensitive button ignores clicks until cursor re-enters it
> https://bugs.launchpad.net/bugs/22930
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

The resolution is in process. Check the upstream bug (gnome-bugs #56070) for more detail.

Sorry, I post a comment here because I don't see this bug listed in my own list (even if I am a subscriber from duplicates).
It's just a test.

While installing Gutsy Tribe 4, I discovered that this bug seems to have been fixed. Has anyone else discovered the same?

I'm on Gutsy Tribe 4 and the problem isn't fixed for me, buttons still just accept one click. Tested on two different windows.

This bug is pretty annoying.
A very acessible way to reproduce it without using fancy wizards or test programs is to just use xsane.
Every ever scan I have to move the mouse out of the button then in again. It's very annoying and because of that I often have to use the keyboard to scan large sets of images.
A newbie wouldn't be very happy though.
A fix is necessary, even because of the age of this bug!

Looks as though this bug has been around since 2001. Sadly it retains an upstream priority of normal which ignores the very serious impact it has on Ubuntu first impressions and greatly highlights one of the problems with FOSS.

Given what has been a very poor track record on this bug why doesnt Canonical do a workaround for this bug so the installer atleast is not effected. I noticed the following in the upstream bug discussion:

"For what it's worth, developers can work around this bug by simply hiding/showing the button after they make the button sensitive again. This will too fast for the user to see, and it will allow them to click the button without moving their mouse from the button."

I hadn't noticed that workaround the last time I looked at the upstream bug (previous workarounds were much worse). I'll look into that, thanks.

I first noticed this also around 2001 ish, but in windows!!
(is this the first cross platform bug?!)
as nothing has been done in *over* 5 years, I think
some kind of patch would be rather nice...

nullack wrote:
> Looks as though this bug has been around since 2001. Sadly it retains an
> upstream priority of normal which ignores the very serious impact it has
> on Ubuntu first impressions and greatly highlights one of the problems
> with FOSS.
>
> Given what has been a very poor track record on this bug why doesnt
> Canonical do a workaround for this bug so the installer atleast is not
> effected. I noticed the following in the upstream bug discussion:
>
> "For what it's worth, developers can work around this bug by simply
> hiding/showing the button after they make the button sensitive again.
> This will too fast for the user to see, and it will allow them to click
> the button without moving their mouse from the button."
>
>

Getting this bug fixed, along wth 42532, would be an amazing accomplishment!

We are many people who have been waiting for a solution to this bug and others. More and more bugs are heaping up and lagging behind. Therefore I made a new blueprint request, which is simply called "fix-bugs". You can find it here: https://blueprints.launchpad.net/ubuntu/+spec/fix-bugs

If you also think that the Ubuntu team should make bug fixing a priority, please support my request.

The Ubuntu team could support the idea by tagging it with a high priority and implementation milestone.

Thanks. :)

the issue is a lack of manpower to work on those bugs, a specification is not going to make that better and there is not a lot to specify there

Then use the manpower that's introducing new features!

Bug fixes are far more important that new features

      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

that's not that easy, there is a right balance between new features and bug fixing to find, next cycle will get extra bug fixing since hardy will be a lts version

While I am new to Ubuntu, I have over a decade of professional experience in
IT projects and I am so shocked that someone with an Ubuntu email address
would actually make the statement that Sebastien has made I feel compelled
to respond with my own points. The importance of producing robust, stable,
easy to use software in IT projects is fundamental. Ubuntu talks about the
"myth" that it is only a desktop OS - well, what person in their right mind
is going to install a distro with the approach that bugs are ok, we'll wait
for LTS. Or even someone wanting to use the distro on a business
workstation. I respect your right to present your views Sebastien but I also
have a right to explain why I fundementally disagree. Canonical should wisen
up and understand the millions of complaints MS receives about bugs in their
software and the attitude of the general population about wanting reliable
software that "just works". How can anyone honestly expect Ubuntu to
threaten MS's dominant position when the releases get out the door into
production when they shouldnt and too many cowboys are contributing to the
project who charge ahead and give a lack of manpower the reason for not
sorting out the quality? Its so incredibly reckless and frivilous. Some of
the bugs are downright dangerous too. Like the GUI bugs with user and group
management - how any software could have been released with that issue
confounds me when I see so many talented people helping on this project.
Gutsy is not looking any better - in fact many of the new features have
presented me with new bugs in the many tests Ive done and the release date
for that looms ever closer. Gutsy is unusable for the LiveCD and I have
continue to have numerous bugs making the alternate install painful. New
features should indeed be stopped and the build brought back to basics in a
major bug fix - forget about a "bug day" and "bug hugs", Ubuntu needs a bug
fix release. Otherwise Canonical is going to continue to frustrate users
coming over from Windows with silly bugs like the one in this thread,
companies wont be using it due to serious bugs like the problems with GUI
user/group management and the rest of the Linux community will increasingly
regard Ubuntu as a distro for cowboys that moves too quickly and doesnt
bother with due diligence in quality assurance.

nullack, don't you think there is some exageration in what you wrote? What is shocking in saying that we there is a right balance between new features and bug fixing? We still try to fix everything we consider as critical before each version, maybe where we disagree is on whether this particular bug is that important. Sure it's annoying but there is also thousand of crash bugs open on launchpad and other important issues and this one might not be the top one.

Lot of new features has landed this cycle and we agree that some stabilization is required that's why we will focus on that next cycle. If you want a polished stable version you should consider using an lts and let non-lts version to desktop users which are looking for a compromise between stability and new technologies.

About Ubuntu being a distro cowboys, you can try any other distribution if you want, the bug you are commenting on is an upstream GTK one and will happen the same way on Redhat, Suse, Mandriva, Debian, Slackware, etc

I noticed this bug over five years ago in Winbloze !!!

reporting this upstream will have little result "theres a workround"

I think submitting a patch upstream that hides then shows a button when
it becomes enabled, might embarrass the people upstream to actually fix
the problem. especially if it comes from an "official" Ubuntu source
(at the very least we'll have a package manager (and other apps) that
work properly!)

and btw if new features are more important than bug fixing then that
makes bug #1 look like spin (sadly)

There's a distro called Vista that has tonnes of new bu... errm
features

      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

sure, there is a balance.

and there are more important bugs to fix. thats why this one has been open
for 5+ years. still, i believe that maybe theres a better way to do it?
this bug can easily be fixed in 15 minutes by the person who wrote this code
in the first place. is that who would normally fix it? can't we just track
him down or something?

maybe thats a way to move the bugs along a bit better, to have people fix
their own code? that way, maybe we won't just be skimming off the top of
the priority list all the time?

On 10/9/07, ChrisC <email address hidden> wrote:
>
> I noticed this bug over five years ago in Winbloze !!!
>
> reporting this upstream will have little result "theres a workround"
>
> I think submitting a patch upstream that hides then shows a button when
> it becomes enabled, might embarrass the people upstream to actually fix
> the problem. especially if it comes from an "official" Ubuntu source
> (at the very least we'll have a package manager (and other apps) that
> work properly!)
>
> and btw if new features are more important than bug fixing then that
> makes bug #1 look like spin (sadly)
>
> There's a distro called Vista that has tonnes of new bu... errm
> features
>
>
> ___________________________________________________________
> Yahoo! Answers - Got a question? Someone out there knows the answer. Try
> it
> now.
> http://uk.answers.yahoo.com/
>
> --
> Newly-sensitive button ignores clicks until cursor re-enters it
> https://bugs.launchpad.net/bugs/22930
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Sebastien, I agree with you there are a lack of manpower and a lot of bug to fix.

But I think that here we are talking about a few number of bug (I guess from 5 to 10) that break the usability of the user interface (as Ross reported above here)
e.g. look at this Bug #66869

I don't think there are much more Bug of this kind so why don't do a Usability Bug fixing Day to take care of them, filtering bugs first to find out how much they are and then fixing together?

Yeah I agree too, it's evident that assigning priorities to bugs isn't a simple thing and I think that ubuntu generally do a very great job.

This bug is one of these exceptions we should care about. It would avoid a lot of time lost in comments. I think that the ubuntu community as much as the linux community would greatly appreciate it. Usability Bug fixing day would be a great idea to do a good work around this!

This bug is far to be trivial, if you look to the upstream comment you will notice it requires a really good understanding of how GTK works and to consider lot of cases and the possible effects, that's really something non trivial and not a quick hack, we don't have GTK maintainers in the Ubuntu team and I doubt somebody here is familiar enough with the code to fix the issue properly quickly

This bug is VERY trivial I happened to be using monodevelop so heres
some mono code with 2 buttons, 1 with the bug and 1 using the work
round

(I have used this workround in c++ before)

 protected virtual void OnGoButtonClicked (object sender,
System.EventArgs e)
 {
  woButton.Sensitive=false;
  wButton.Sensitive=false;
 }

click the go button

move the cursor over one of the 2 test buttons

hit the tab key and the go button looses the focus which re-enables the
buttons one with the work round

 protected virtual void OnGoButtonFocusOutEvent (object o,
Gtk.FocusOutEventArgs args)
 {
  woButton.Sensitive=true;
  wButton.Sensitive=true;

  wButton.Hide();
  wButton.Show();
 }

The wButton shows the correct behaviour. afaik because is all a single
thread the button is never cleared and redrawn, but this hide/show is
enough to make it properly sensitive when the mouse cursor is over it

*** At the very least this should be implemented it synaptic and the
installer ***

I believe that with a simple bit of code in gtk set sensitive that
respects the visible status of the button, this issue would be fixed, I
am not even slightly convinced that this would have far reaching
consequences of a negative nature

At the very least sending a patch upstream would probably prompt what
they would feel the "correct" way of fixing it...

Given the very long history of this problem something like will have to
happen before a "proper" fix happens

      ___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

The hack you describe has already been mentionned on the bug and used in the ubiquity installer. Did you read the upstream bug comments?

why not apply the workround in the installer or synaptic ?

I did look at some of the upstream reports a little while ago, but I
dont remember being convinced that there was any reason why a hack
couldnt be tacked onto the end of the gtk set sensitive code, providing
it respected the visibility status

Have you tried any experiments for yourself?

      ___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

ChrisC: sebastian already said it's been used in the installer!

in the last 10 days since Colin Watson (a maintainer of the installer) acknowledged the workaround and said he would investigate, none of the comments here have been remotely useful, but are spamming a fairly long list of subscribers. Can we stop that now please?

The following comment was written 1st October:-

Excellent suggestions. Regarding the "upstream priority of normal" -
why is this causing the bug to remain unfixed for 6 years now. 6
years! What must people switching to Ubuntu think?

I was speaking to someone just this week who was thinking of switching
to Ubuntu from XP and actually advised them against it as i considered
ubuntu to not yet be ready for mainstream use. It's precisely because
of bugs like this that leads me to this opinion.

On 01/10/2007, nullack <email address hidden> wrote:
> Looks as though this bug has been around since 2001. Sadly it retains an
> upstream priority of normal which ignores the very serious impact it has
> on Ubuntu first impressions and greatly highlights one of the problems
> with FOSS.
>
> Given what has been a very poor track record on this bug why doesnt
> Canonical do a workaround for this bug so the installer atleast is not
> effected. I noticed the following in the upstream bug discussion:
>
> "For what it's worth, developers can work around this bug by simply
> hiding/showing the button after they make the button sensitive again.
> This will too fast for the user to see, and it will allow them to click
> the button without moving their mouse from the button."

that's not likely something upstream will change this cycle not something we will patch in a distro specific way

Well anyway, does someone tested this on Hardy? I can't reproduce this bug in ANY gnome app at all in latest Hardy alpha 5. Can someone test this please?

I can, in Synaptic package manager for instance.

Upstream will try to settle on the best fix for this bug during Berlin hackfest (March 10-14), hopefully Ubuntu will be able to incorporate results into Hardy if any are produced

I just discovered that this bug does not exist for ubuntu 64 bit. I can still reproduce it in up-to-date Gutsy/Hardy i386 but not with a up-to-date Hardy amd64, can someone confirm this?

i certainly have this bug on gutsy 64 bit.

On Wed, Feb 27, 2008 at 5:49 PM, Saïvann Carignan <email address hidden> wrote:

> I just discovered that this bug does not exist for ubuntu 64 bit. I can
> still reproduce it in up-to-date Gutsy/Hardy i386 but not with a up-to-
> date Hardy amd64, can someone confirm this?
>
> --
> Newly-sensitive button ignores clicks until cursor re-enters it
> https://bugs.launchpad.net/bugs/22930
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Well that's very strange..

I can't reproduce this bug on my i386 laptop and my AMD64 computer on Hardy alpha 5 even from the LiveCD. My laptop did have that bug in Gutsy but this bug is gone with Hardy.

I can still reproduce this bug with a VirtualBox console with Hardy alpha 5, but not on any physical computer that I own.

I found it, that was just because my computer now uses compiz. The bug does not appear with compiz, only metacity.

gotcha, so i can't tell, is it getting fixed?

On Thu, Feb 28, 2008 at 5:26 PM, Saïvann Carignan <email address hidden> wrote:

> I found it, that was just because my computer now uses compiz. The bug
> does not appear with compiz, only metacity.
>
> --
> Newly-sensitive button ignores clicks until cursor re-enters it
> https://bugs.launchpad.net/bugs/22930
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I don't think so, that only means that I found a workaround and though that it was fixed, sorry for the noise.

What does "Tags removed: qa-hardy-desktop" mean? Does it mean Canonical aren't aiming to have this bug removed from Hardy?

Sebastian Bacher said : that's not likely something upstream will change this cycle not something we will patch in a distro specific way.

I think that Canonical will prioritize security and crashes before that bug which also seems non-trivial to fix since nobody was able to fix it during several years.

i have this "bug" (or i'd say, annoyance) too, on 7.04 with xfce (but in gnome too) on several machines.
when i start synaptic, i used to move the mouse on the search button while it loads the list, for a faster searching. but when the load completes and the search button becomes active, it's not clickable - have to move the mouse off it and than back, as described in the first post.

i wonder why this couldn't been fixed since years? strange. but i'm not complaining, ubuntu is still a superb little OS. :)

I have rebuild hardy's gtk-2.0 package with the patch at: http://bugzilla.gnome.org/show_bug.cgi?id=56070#c153

It fixes the bug, but needs more testing.

Victory!! This bug is now fixed upstream

the bug has been fixed upstream now

WoW

\o/

This bug was fixed in the package gtk+2.0 - 2.13.6-0ubuntu1

---------------
gtk+2.0 (2.13.6-0ubuntu1) intrepid; urgency=low

  * New upstream version:
    - Fix problems on 64-bit Windows
    - Fix a long-standing, well-known problem with the handling
      of insensitive buttons, bug 56070 (lp: #22930)
    - Fallback to Xinerama if the Xrandr implementation is just a stub
    - gdk_threads_add_timeout_seconds[_full]: New functions with
      second-granularity to complete the set of gdk_threads_ timeout
      functions
    - Support rendering icons with emblems specified as GEmblemedIcon
    - GtkFileChooser has a GFile-oriented API now, functions
      for creating filechoosers with specific backends have been
      deprecated, since GIO is used directly.
    - GtkAdjustment has been sealed, adding getters and setters
      for all struct fields.
    - Bugs fixed:
    544265 GDK assumes XFIXES extension
    543915 "Sole completion" translation issue
    544510 SetTimer callback signatures has the wrong type
    544390 evince crashes after clicking print
    361561 StatusIcon signals not documented as definitely public API.
    368234 Incorrect tabs rendering during reorder with rounded themes
    545976 Deprecate gtk_file_chooser_*_with_backend
    545978 Make filechooser GFile API public
    544863 gtkquartz.h not included in released 2.13.5 package
    424207 printing hangs on unreachable cups server
    56070 Can't click button after setting it sensitive
    545931 small documentation typos
    344383 use po/LINGUAS
    65818 rename gtk_window_set_default() and add getter for it
    539733 No way to control treeview separator height
    523950 GtkTreeModelFilter's visible function may get an empty...
    526575 Missing return type in gtk_ui_manager_get_toplevels...
    429411 add style properties to set minimum progressbar w...
    429427 Add "arrow-spacing" style property to GtkRange
    544302 GtkStatusIcon should support GIcon
    339699 implement gtk_print_operation_set_show_dialog for...
    538686 gtkprintoperation-win32.c: devmode_from_settings
    540379 gtk_tree_view_enable_model_drag_dest and ...
    544684 Win64 issue, window handles are assumed to be 32-bit
    540834 Insensitive widgets cannot be grabbed
    515596 GtkUIManager's embedded UI definition example is invalid
    534979 GtkImageMenuItem is a bin but has two children
    382291 Automatically dim the combobox when the model is empty
    545982 missing braces cause bogus warnings when using GtkBuilder
    544858 Seal GtkAdjustment
  * debian/control.in:
    - updated libglib requirement
  * debian/patches/080_dont_free_gettext_values.patch:
    - dropped, the change is in the new version
  * debian/patches/009_gtk-export-filechooser.patch,
    debian/patches/070_mandatory-relibtoolize.patch:
    - new version update
  * debian/rules:
    - updated shlibs version

 -- Sebastien Bacher <email address hidden> Tue, 05 Aug 2008 22:10:54 +0200

Yes, this bug is really fixed in intrepid, HUGE thanks to all people who worked on this.

Will this bug be fixed in Hardy?

This is one of my _major_ gripes with everything GTK.

* is a sad panda *

OK,

" Declined for Hardy by Sebastien Bacher " means it won't ..

Why did it take 3 years to be fixed? Is it really that hard to fix?