84386 - Buggy gtk focus is of course buggy.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: GTK Widget, defect)

Description

[Joseph Elwell]

Blizzard: please excuse my choice of component.

In our code, we call nsIDOMWindowInternal::Focus() when someone sends you a
message that you already have a window open for. If this window is minimized in
a buggy old version of gtk, the window opens but the focus is not set correctly
in the window. The focus appears to be set to our editor field, but it is in
fact not set there, and one needs to click away and then back to set the focus.

Can you help? In our bug there lies this comment:
------- Additional Comments From Joaquin Blas 2001-05-30 14:30 -------
So it seems you can't reproduce this bug on RH 7.0 or later, but I do see it on 
my stock RH 6.2 machine running gdm (Gnome Desktop Manager) with gtk+-1.2.5-2.

To see this bug the AIM window has to have focus before you minimize it, after 
you minimize it, don't give any other window on the desktop focus.

When the person you were talking to via AIM, sends a message back, the window is 
programatically raised, and the window manager gives the window the appearance 
that it has focus (the title bar is blue), but it never calls our gtk focus 
callbacks/handlers.

Now, when you click in the AIM edit/compose area the nsWindow::SetFocus() code 
falls into the if clause:

     // we need to grab focus or make sure that we get focus the next
     // time that the toplevel gets focus.
     if (top_mozarea && !GTK_WIDGET_HAS_FOCUS(top_mozarea)) {
       ...


       // !!hack alert!!  This works around bugs in version of gtk older
       // than 1.2.9, which is what most people use.  If the toplevel
       // window doesn't have focus then we have to unset the focus flag
       // on this widget since it was probably just set incorrectly.

       ...
     }

which does a return before sFocusWindow is set, so it is always null. In any 
case a focus event does seem to travel through the layout system so that's why 
the caret appears, but when you type a key, the nsWindow/nsWidget code tries to 
retarget key events to what it thinks is the "focused" window (sFocusWindow) but 
since it's null, it sends it to the default window which is the wrong one.

So the short version of this is that there are 2 problems. The first one having 
to do with gdm/gtk not calling our registered focus callbacks when the window is 
raised. The 2nd is that our gtk nsWindow focus code that tries to work around 
focus bugs, in early versions of gtk, is also preventing us from setting 
sFocusWindow.

[e-mail] is really the person that is most knowldgeable about 
hacking around these gtk problems.

Before I forget, the reason why it seems to work ok in gdm on RH 7.x systems, is 
that when the AIM window is raised, it is *not* automatically given focus by the 
window manager (title bar is still gray), you have to manually click in the 
window to give it the appearance that it is focused.

I talked to blizzard and he suggested that a bug be filed in bugzilla about this 
issue. I'm not exactly sure how he is going to reproduce this though since AIM 
is only in-house.

Comment 1

[Joseph Elwell]

I will buy you presents, beer if you prefer, if this bug is fixed for m0.9.2.

Comment 2

[Christopher Blizzard (:blizzard)]

We really need to fix the focus architecture.  I'm getting so sick of polishing
this turd.

Comment 3

[Christopher Blizzard (:blizzard)]

Moving out.

Comment 4

[Syd Logan]

Gonna land in 0.9.7?

Comment 5

[Neil Deakin]

No longer relevant I think.