Closed
Bug 202145
Opened 22 years ago
Closed 19 years ago
Bringing window to front should give it focus
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 295447
People
(Reporter: cay.horstmann, Assigned: asa)
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
When selecting a menu option such as Window->Navigator or Window->1, the
requested window is brought to the top, but it doesn't have focus. As a result,
further keystrokes are directed to the obscured but focused window. This is a
problem for driving Mozilla without a mouse.
Reproducible: Always
Steps to Reproduce:
1.Click on a browser window
2.Select Window->Mail
3.The mail window is brought to the top.
Actual Results:
Look at the title bar--the mail window doesn't have focus.
Expected Results:
It should have focused the window that it brought to the top.
This problem occurs with both WindowMaker 0.80.2 and the version of Gnome that
came with Red Hat 8.
Comment 1•22 years ago
|
||
Nope, this will never be fixed. Applications never ever grab focus on Unix.
Use alt-tab if you're that worried.
(Bryner and I have been round and round about this before.)
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Comment 2•21 years ago
|
||
Well, I don't know if this is related, but if I use window.focus() to try to
achieve the affect of a popunder using Mozilla under Linux, the main window
returns to the top but does not receive focus.
Oddly, the posted testcase works for me.
Reporter | ||
Comment 3•21 years ago
|
||
Well, I can appreciate that people who know more than I have been "round and
round" this issue, but I am not entirely satisfied.
The current behavior is inconsistent. When you select Window->Mail for the FIRST
time, then the window has focus. When you switch back to Window->Navigator, and
to Window->Mail AGAIN, then the window comes to the front but has no focus.
Frankly, I don't really see any sense WHY anyone would want the mail window on
top but not focused.
Alt+Tab is a tedious workaround, particularly if many windows are open.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 4•21 years ago
|
||
The fact that the window is focused the first time it comes up is only because
of the fact that the window manager happens to do that. It has little to do
with Mozilla.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 5•21 years ago
|
||
It is not true that "applications never ever grab focus on Unix". Try Eclipse on
Linux. It does the right thing--selecting another window from the Window menu
brings it to the front and gives it focus.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 6•21 years ago
|
||
Great, I'll file a bug against the eclipse guys.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 7•21 years ago
|
||
I am still bothered by this, and posted a query on the WindowMaker mailing list.
(That's the window manager I use, although the behavior is the same under
Gnome). Here is what the local guru responded:
Jim Knoble <jmknoble@pobox.com> wrote:
> Wrong. The user's expectation is that, by choosing the Mozilla Mail
> window from Mozilla's menubar, Mozilla will "switch" to the Mozilla
> Mail program. Mozilla is obviously already raising the Mozilla Mail
> window using XRaiseWindow(3) (or a wrapper around it). Why shouldn't
> the Mozilla Mail window also request the input focus using
> XSetInputFocus(3)? Remember that this is an explicit action requested
> by the user; without asking for the input focus, the raised Mozilla
> Mail window is merely obscuring the stuff beneath it, and the action is
> ineffective. If they don't want to deal with window focus, Mozilla
> should get rid of the facility for switching to the Mail window.
I couldn't have said it better myself :-)
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 8•20 years ago
|
||
btw, is there any way to focus the window from code? (win.focus doesn't seem to
set the keyboard focus)
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 9•20 years ago
|
||
WONTFIXing. don't reopen. seriously.
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 10•19 years ago
|
||
Well, I did reopen it, just to prod someone, anyone, to come up with a statement
why it is better to keep the current behavior even though no user will be
satisfied with it.
Is it hard to implement a user-friendly behavior so that it works reliably in X
under multiple window managers? Would it break something else? FWIW, I just
checked the OpenOffice 2.0 beta, and it does the same as Eclipse does, namely
focus a window that is being brought on top with the Window menu.
Simply saying "No, we know better than the users, and we know better than the
Eclipse folks, but we won't tell you why" seems rather arrogant.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 11•19 years ago
|
||
See bug 295447.
I posted my analysis and a possible fix.
Please note, this issue blocks Bug 283103, Bug 260560 which are well-known security issues.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 12•19 years ago
|
||
it is a possible fix if
change gtk_widget_grab_focus(owningWidget);
to gtk_window_present((GtkWindow*)owningWindow->mShell);
in widget/src/gtk2/nsWindow.cpp
Comment 13•19 years ago
|
||
duplicate this, since I posted a patch on bug 295447
*** This bug has been marked as a duplicate of 295447 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•