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 125492 - Possibly incorrect warning re: SetInputFocus
Possibly incorrect warning re: SetInputFocus
Status: RESOLVED NOTGNOME
Product: metacity
Classification: Other
Component: general
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 128096 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-10-25 19:05 UTC by Gregory Merchan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Change the warning to a meta_topic; improve the behavior (1.96 KB, patch)
2004-09-30 20:07 UTC, Elijah Newren
accepted-commit_now Details | Review

Description Gregory Merchan 2003-10-25 19:05:11 UTC
I've seen this warning a few times:

  Window manager warning: Working around an application which called
  XSetInputFocus (None) or with RevertToNone instead of RevertToPointerRoot,
  this is a minor bug in some application. If you can figure out which
  application causes this please report it as a bug against that application.

I've searched to no avail for the app causing it. I suspect the bug is
in Metacity itself. It seems to trigger when there are keystrokes just
after dismissing a dialog, before focus returns to the MRU window, but
I can't reliably reproduce it. I have the best luck with Gedit. Run
Gedit, type something, quit, then select "Don't Save" when the alert
appears.

Also, the warning is misleading: Apps should use only RevertToParent.
(Maybe the WM should too?)
Comment 1 Rob Adams 2003-10-25 19:48:28 UTC
I haven't looked at the code but I'm reasonably certain that this
warning is issued whenever there is no focused window.  Metacity
catches this and resets the focus so that keyboard events can be
intercepted by metacity.

Perhaps this is happening somehow when a window is deleted?  Who knows.
Comment 2 Havoc Pennington 2003-10-25 20:08:07 UTC
I don't see how focus would get set to None if nobody calls
XSetInputFocus() with window None or RevertToNone. Keith is there any way?
Comment 3 Rob Adams 2003-12-20 19:44:18 UTC
*** Bug 128096 has been marked as a duplicate of this bug. ***
Comment 4 Keith Packard 2003-12-21 20:54:49 UTC
The protocol spec says that focus can only be set by SetInputFocus or
when the current focus window becomes NotViewable.  Looking at the
code, that seems to be accurately implemented.
Comment 5 Gregory Merchan 2004-02-01 17:58:32 UTC
There is another way for focus to be set to None. From proto.txt,
which came with XFree86:

  If the focus window later becomes not viewable, the new focus
  window depends on the revertto argument.  If revertto is Parent,
  the focus reverts to the parent (or the closest viewable ancestor)
  and the new revertto value is taken to be None.
Comment 6 Elijah Newren 2004-02-02 05:33:57 UTC
I actually saw this warning quite a few times while I was trying to
test my _NET_WM_USER_TIME stuff, though I'm sure that was unrelated. 
I'm pretty sure I can duplicate it (and perhaps even fine a 100%
repeatable case).  Would you like me to try and report back, or is
this more of a procedural issue at this point?
Comment 7 Rob Adams 2004-02-15 05:52:41 UTC
evolution seems to cause this warning fairly frequently when "New
Message" windows are closed, though not invariably.  Based on
Gregory's research though, I'd have to say at this point that the
warnings are spurious, and since the workaround is in place, they are
also harmless.

We should remove the warning.
Comment 8 Elijah Newren 2004-09-16 21:42:36 UTC
This is really easy to reproduce once you know how...and I just barely figured
out how while doing massive testing for bug 152000.

Okay, steps to reproduce: In any focus mode:
1) open a new gnome-terminal window
2) open a second tab in the gnome-terminal window
3) Click the X button to close the window (or press Alt+F4 or whatever;
   just don't close the tabs individually)
4) Note the little confirmation window that comes up.
5) Make sure that when you press the "Close all tabs" button in the
   confirmation window that comes up, that the default focus window will be
   the gnome-terminal window that is about to be closed (shouldn't require any
   effort, just be careful not to interact with other windows).
6) Actually click on the "Close all tabs" button

I can duplicate with other apps too (e.g. gedit or several of the gnome-games).
 The basic idea is to get a confirmation dialog when trying to close a window
and have things setup such that Metacity would want to focus the window when the
dialog shuts down--and then run into the problem that closing the dialog causes
the window to close too.
Comment 9 Havoc Pennington 2004-09-16 22:16:27 UTC
Gregory's cite seems to explain this:
  If the focus window later becomes not viewable, the new focus
  window depends on the revertto argument.  If revertto is Parent,
  the focus reverts to the parent (or the closest viewable ancestor)
  and the new revertto value is taken to be None.

The focus window vanishes, we revert to parent and then revert to goes back to None.

So, I guess we need to remove the warning from metacity, though I don't think we
want to change the behavior. An X extension to let us specify "revert to some
specified window" (with side effect that RevertToNone will never be used) would
be welcome.

Existence of RevertToNone is basically a bug in the X protocol in my opinion, as
it amounts to RevertToUserIsFucked and the root window is always available as a
sane default to revert to.

Comment 10 Elijah Newren 2004-09-30 20:07:38 UTC
Created attachment 32127 [details] [review]
Change the warning to a meta_topic; improve the behavior

This patch makes the warning into a meta_topic and makes the comment refer to
this bug.  It also improves the behavior:  we know which window should be
focused (the default_focus_window), so we might as well focus it.  (When we
used to have three different focus window functions and we didn't maintain the
invariants mentioned in doc/how-to-get-focus-right.txt, we couldn't have done
much better and focusing the no_focus_window was probably close to as sane as
we could get).

This patch depends on the one in bug 152000 first being applied.  I could have
made it not depend on that one, but then this patch would have to be updated as
soon as the other was applied (since focus_default_window will then need a
timestamp).
Comment 11 Rob Adams 2004-10-02 16:01:18 UTC
Comment on attachment 32127 [details] [review]
Change the warning to a meta_topic; improve the behavior

This looks fine pending the actual existencs of a function called
meta_display_thou_shalt_return_a_timestamp (display) :-)
Comment 12 Havoc Pennington 2004-10-03 17:06:13 UTC
I agree that this is sensible, except that
enter_notify_events_will_handle_this probably has to go away as mentioned on
bug 152000
Comment 13 Elijah Newren 2004-10-04 20:39:53 UTC
Comment on attachment 32127 [details] [review]
Change the warning to a meta_topic; improve the behavior

I committed.  I leave this bug open in case someone wants it as a reminder to
file a bug against Xorg.
Comment 14 Elijah Newren 2004-12-20 19:09:46 UTC
I filed https://bugs.freedesktop.org/show_bug.cgi?id=2117.  Since we have a
workaround (even if hacky) and the core bug is in X, I'm resolving as NOTGNOME.