Bug 165924 - Next button requires mouse move before working
Summary: Next button requires mouse move before working
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk2
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact:
URL:
Whiteboard:
: 186249 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-14 17:08 UTC by michael mastrangelo
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-16 20:11:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 56070 0 None None None Never

Description michael mastrangelo 2005-08-14 17:08:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Description of problem:
When installing Fedora Core 4 I have to click several times on "next" and sometimes even move my mouse off the "next" button before the click is registered...

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. try clicking next next next when installing...
2.
3.
  

Actual Results:  some of the next didnt register... (had to click it several times)
other times i had to move my mouse off next and then try again...

Expected Results:  next should work on the first click

Additional info:

Comment 1 Jeremy Katz 2005-08-15 18:37:33 UTC
Hmm, I haven't seen this here.  What language are you installing in and what
sort of hardware do you have?

Comment 2 michael mastrangelo 2005-08-15 21:32:16 UTC
english - dell 700m 

this lists my hardware
http://web.ics.purdue.edu/~mmastran/fedora-core-3/

Comment 3 Paul Nasrat 2005-08-15 21:52:16 UTC
Is this only on the screen prior to package installation?  If so there is a
known issue on that screen where you have to defocus the button before clicking
that is being investigated - the bug no. elludes me know I'll find and update
this bug when I do.

Else if it is on more than just that screen, if you switch to tty2 and type
dmesg are there any serio/input device errors?

Comment 4 michael mastrangelo 2005-08-16 00:40:44 UTC
It may only be that screen...

If something messes up and I have to reinstall I will let you know which exact 
screens...

Comment 5 David Timms 2006-01-30 13:08:50 UTC
Paul: [FC5T1&2] This is easily generated, and seems to me to be a fault in the
underlying toolkit (I see it in for example one of the audio apps that displays
a "helper wizard" the first time that you run the app - Rhythmbox (0.8.8,fc4) -
Welcome to Rhythmbox and Music Libary Setup.)

Here is how you can guarantee (maybe to strong) that this is seen:
1. In any wizard style screen, move your mouse and place it over the top of the
next button.
2. click the mouse button, but do not move the mouse cursor off the next button.
3. on the next screen, use keyboard accelerator eg to turn some option on/off
etc.  (also happens if the step 2's action causes a change of focus to a dialog
for example -that you then clear with a key like enter/escape).
4. click (only) the mouse.

what happens:
the button under the mouse receives focus, but no matter how many times you
click it, the button event is not activated. (the click is getting partially
actioned)
what should happen:
if you click a button (regardless of the above), the button event should be
activated.

This is normal (for me at least) user behavior (- some stuff is easier to do by
keyboard!, and saves moving the mouse pointer around the screen, when you really
 want to "just do it").

Workaround:
a. use next kb shortcut. Alt-N
b. move mouse out of button, and back in again.

This is a real time killer: eg at the final install step, have this happen
(where normally nothing seems to happen for some minutes, before you get a
dialog). At this point a click the mouse but it didn't trigger event. I came
back 1.5 hours later expecting install to be complete, and it still hasn't
started :-{  
It does not have to be the next button, any button that stays in the same
position between screens (helper apps are the obvious ones).

Got me quite a few times in this past month, but I think this has been around
since FC4 at least, but given it wasted so much of my time lately I have worked
out how to repeat it.

Comment 6 Chris Lumens 2006-03-02 21:48:58 UTC
Man, this one's aggravating.  It appears to happen after any sort of wait or
progress window has popped up.  We need to get some desktop people over to take
a look and see if they have any ideas.

Comment 7 Chris Lumens 2006-03-22 15:15:00 UTC
*** Bug 186249 has been marked as a duplicate of this bug. ***

Comment 8 Otto Rey 2006-09-19 01:58:04 UTC
Ummm... i think that is expected behaviour to prevent unintentional clicks (see
before click :) ). This bug must be marked "NOT A BUG" - "CLOSED".

Comment 9 David Timms 2006-09-19 13:38:45 UTC
No, unintentional, non-intuiive behaviour that the upstream project is working
on {with Patch, against 2.9.1} for their next version. see gnome bugzilla link
below.

and http://bugzilla.gnome.org/show_bug.cgi?id=112404 for perhaps a different
incarnation of the same ?

It might make sense to change package to gtk+, though ?

Comment 10 Matthias Clasen 2006-09-22 01:05:03 UTC
This is likely a result of a well-known, longstanding gtk bug: If a widget becomes
sensitive while the pointer is already over it, it doesn't get a focus in event.

See http://bugzilla.gnome.org/show_bug.cgi?id=56070

I do not think this is a blocker bug, however. 
GTK+ has had this issue for years.

Comment 11 David Timms 2007-04-03 14:29:33 UTC
It seems that this issue is fixed in rawhide as of f7t3 2003-03-2?. During the
anaconda install within a vmware vm guest, if you keep your mouse cursor above
the next button, and other dialogs pop up {that you close with keyboard}, then
clicking the next button actually goes to the next screen. I am yet to test on a
real machine.

{Is one of the patches for the gtk bugs mentioned above been applied, or is
anaconda using workarounds to achieve the fix ?}


Note You need to log in before you can comment on or make changes to this bug.