After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 127775 - Desktop never gets keyboard focus unless all windows are minimized
Desktop never gets keyboard focus unless all windows are minimized
Status: RESOLVED DUPLICATE of bug 115072
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal major
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 127788 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-11-24 00:08 UTC by Ricardo Veguilla
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4


Attachments
patch for CVS HEAD (753 bytes, patch)
2003-12-08 20:17 UTC, William Jon McCann
none Details | Review

Description Ricardo Veguilla 2003-11-24 00:08:57 UTC
Description of Problem:

Desktop never gets keyboard focus unless all
windows are minimized when mouse over window
selection is activated.

Steps to reproduce the problem:
1. Activate "Select Windows when the mouse moves
over them" on the "Windows Preferences" dialog.
2. Minimize all windows. 
3. Open one window(any app) resize it so that some
  desktop icons are visible. 
4. Click a dektop icon
5. Try deleting the icon or navigating the desktop
with the keyboard
 
Actual Results:
The previously opened window retains the keyboard
focus, so no keyboard operation can be performed.
The Desktop only recieves the keyboard focus when
all windows are minimized.

Expected Results:
The Desktop should recieve the keyboard focus
after clicking on any desktop icon.

How often does this happen? 
This only happens if the "Select Windows when the
mouse moves over them" option is on, if this
option is off, the Desktop recieves keyboard focus
properly.  


Additional Information:
Using metacity-2.6.3 and nautilus-2.5.1.1
Comment 1 Jeremy Browne 2003-11-25 03:48:55 UTC
*** Bug 127788 has been marked as a duplicate of this bug. ***
Comment 2 Jeremy Browne 2003-11-25 03:52:26 UTC
This also applies to text entry fields in gnome-panel, and presumably
any other application which uses the same window manager hints as
panel and the desktop do.

GNOMEVER2.4 and version 2.6.x, but I guess I can't change those fields.
Comment 3 Ricardo Veguilla 2003-11-25 04:51:16 UTC
changed keywords to GNOMEVER2.4, GNOMEVER2.5
Comment 4 William Jon McCann 2003-12-08 20:17:22 UTC
Created attachment 22224 [details] [review]
patch for CVS HEAD
Comment 5 William Jon McCann 2003-12-08 20:19:43 UTC
The above patch seems to fix this problem for me.  However, I have to
assume that the DOCK windows are filtered out for a reason so this
patch may break something else.
Comment 6 Rob Adams 2003-12-08 20:54:25 UTC
this is actually related to the raise-on-click thing -- we don't
maintain the mouse grab so we never see the clicks.  But obviously for
focus-follows-mouse this is really broken for windows that aren't
focused on enter, such as the desktop and the dock windows.

Even with this patch, you still can't focus the desktop window.  We
really need to figure out some sort of solution for the grabbing.

*** This bug has been marked as a duplicate of 115072 ***
Comment 7 William Jon McCann 2003-12-08 21:05:58 UTC
That bug does not specifically address the broken behavior of the
gnome-panel.  Should I open a new bug?  The panel is seriously
disabled when sloppy focus is on.

dictionary applet - unable to enter text
command line applet - unable to enter text
clock applet - unable to use keyboard navigation

I'm probably misunderstanding but none of those things should "raise"
but just receive focus.  They should also not require a click to get
focus.
Comment 8 Rob Adams 2003-12-08 21:10:50 UTC
yes but its the same bug, really.  In the end both bugs are caused by
the fix for Bug 102209.  The fix for one is the fix for the other.