Red Hat Bugzilla – Bug 165924
Next button requires mouse move before working
Last modified: 2007-11-30 17:11:11 EST
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:
Hmm, I haven't seen this here. What language are you installing in and what sort of hardware do you have?
english - dell 700m this lists my hardware http://web.ics.purdue.edu/~mmastran/fedora-core-3/
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?
It may only be that screen... If something messes up and I have to reinstall I will let you know which exact screens...
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.
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.
*** Bug 186249 has been marked as a duplicate of this bug. ***
Ummm... i think that is expected behaviour to prevent unintentional clicks (see before click :) ). This bug must be marked "NOT A BUG" - "CLOSED".
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 ?
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.
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 ?}