Closed
Bug 84386
Opened 23 years ago
Closed 6 years ago
Buggy gtk focus is of course buggy.
Categories
(Core Graveyard :: Embedding: GTK Widget, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: jelwell, Assigned: blizzard)
References
()
Details
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. blizzard@mozilla.org 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.
Reporter | ||
Comment 1•23 years ago
|
||
I will buy you presents, beer if you prefer, if this bug is fixed for m0.9.2.
Assignee | ||
Comment 2•23 years ago
|
||
We really need to fix the focus architecture. I'm getting so sick of polishing this turd.
Status: NEW → ASSIGNED
Whiteboard: want for mozilla 0.9.2
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Updated•23 years ago
|
Whiteboard: want for mozilla 0.9.2
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → ---
Updated•15 years ago
|
QA Contact: pavlov → gtk-widget
Updated•12 years ago
|
Product: Core → Core Graveyard
Comment 5•6 years ago
|
||
No longer relevant I think.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•