Open
Bug 76854
Opened 24 years ago
Updated 2 years ago
Mozilla ignores keyboard input if a window manager is not used
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
NEW
People
(Reporter: kleist, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: embed, Whiteboard: [wgate] have patch; need testing; r=? sr=?)
Attachments
(2 files)
1.20 KB,
application/vnd.mozilla.xul+xml
|
Details | |
2.39 KB,
patch
|
Details | Diff | Splinter Review |
Build ID: 2001041212
Unless a Window manager is used, Mozilla seems to ignore keyboard input.
This is the first UNIX/Linux application I've encountered during my
ten hacking years which displays this strange behaviour.
- So what's the problem? you may ask. - He who doesn't use a window manager
doesn't deserve Mozilla anyhow.
Well, I found this when trying the commercial X server for Mac OS X
"Xtools" < http://www.tenon.com/products/xtools > . Typically it uses
the native (Aqua?) windowing system, hence no X:ish window manager.
See also the discussion thread at
< http://www.tenon.com/products/xtools/ubb/Forum1/HTML/000205.html > .
I've tried Mozilla without a window manager via the vnc client on my
laptop, and keyboard input is ignored now as well.
Please note that the mouse works fine.
Weird, eh?
Reporter | ||
Comment 2•24 years ago
|
||
Possibly related to bug 71920 ?
Quote from netscape.public.mozilla.unix:
>> that Mozilla may have a design flaw which prevents it to work if no
>> window manager is used.
> To me it sounded so weird that I killed fvwm just to try - and it's
> true, the keyboard is ignored by Mozilla (0.8.1 on a Debian GNU/Linux
> using Gnome on XFree 4.0.2) when the wm isn't present.
This is not weird at all. :-) X11 applications must either take the
input focus (i.e. the property "this window receives keyboard input")
themselves or rely on the window manager to assign it. The latter is
the normal case. See ICCCM (part of X11 docs) section 4.1.7.
I think this is an issue of GTK+, which handles the gory X11 details,
rather than Mozilla.
Reporter | ||
Comment 3•24 years ago
|
||
Obviously Mozilla is in good company, "StarOffice" is said to behave the same way.
Comment 4•24 years ago
|
||
ccing blizzard, who knows something about GTK focus stuff.
Keyboard input does not work with XDMCP under linux and M 0.81. It did work with
M7.Although if you use the mouse to open the file menu some keyboard short cuts
do work! This does not have to do with GTK as other GNOME apps started from
XDMCP do work just fine as well as mozilla M7. To test this you may add a line
to gdm/Init/Default - xterm -e mozilla -P default -
This test case assumes that you are starting linux in runlevel 5 and have set
MOZILLA_FIVE_HOME. You could also add the above line to Xsetup_0 if you are
using XDM as the login.
e-mail massey@stlouis-shopper.com
Comment 6•24 years ago
|
||
You might want to upgrade your version of gtk+ to the most recent version. Some
of the more recent versions fixed problems related to running without a window
manager. You also might want to try the patch in 76617.
I see this with GTK 1.2.10.
This behavior is easily seen with Xnest.
1) Launch Xnest.
2) Launch mozilla into the Xnest. Mozilla doesn not accept keyboard
input.
3) Launch a window manager into the Xnest server; almost any one will do
but the minimal ones are probably best. Mozilla responds to keys.
4) Kill the window manager and the behavior reverts.
Comment 8•24 years ago
|
||
Well, crap. This is my bug. I thought that I had fixed this but it appears
that it's not perfect quite yet. More Xlib hackery to come!
Assignee: joki → blizzard
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•24 years ago
|
Severity: normal → minor
Whiteboard: want for mozilla 0.9.1
Target Milestone: --- → mozilla0.9.1
I see this happen with twm (my usual window manager) as well as with no window
manager. Other Gnome apps work fine for me.
This is on both Redhat 6.0 and Debian 2.2.
After reading this bug report, I tried it with enlightenment and it works
properly with that.
So I tried more with twm: it does work if you explicitly set the focus for that
window or have it set for "click to focus" (either way calls twm's f.focus on
that window). Default mode for twm is "focus follows mouse", which is what's
having this problem.
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.3
Comment 10•24 years ago
|
||
An 05-19-09 nightly appears to work with twm and other wm's. However, it
still fails to work in an Xnest server without a wm.
Comment 12•24 years ago
|
||
*** Bug 91446 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Whiteboard: want for mozilla 0.9.1
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 13•24 years ago
|
||
*** Bug 78562 has been marked as a duplicate of this bug. ***
Comment 14•24 years ago
|
||
*** Bug 93637 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
*** Bug 94565 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
counting dupes of dupes and dupes of the twm relatives marking mostfreq
Keywords: mostfreq
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 17•23 years ago
|
||
*** Bug 98163 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
*** Bug 96847 has been marked as a duplicate of this bug. ***
Comment 19•23 years ago
|
||
Comment 21•23 years ago
|
||
*** Bug 105147 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
our embedding client is currently relatively nonfunctional because of this.
blizzard: can we get an eta or a suggestion about where to look to fix this? (i
can guess and stuff but some help would be nice)
Comment 23•23 years ago
|
||
Track the focus events in gtkmozarea.c and see if they are being properly delivered.
Comment 24•23 years ago
|
||
help.
conclusions:
the following events are available (according to xev)
EnterNotify event, serial 10, synthetic NO, window 0xc0002b,
root 0x26, subw 0xc0002c, time 3153181861, (1420,539), root:(1420,539),
mode NotifyNormal, detail NotifyVirtual, same_screen YES,
focus YES, state 0
KeymapNotify event, serial 10, synthetic NO, window 0x0,
keys: 38 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
VisibilityNotify event, serial 10, synthetic NO, window 0xc0002b,
state VisibilityPartiallyObscured
VisibilityNotify event, serial 10, synthetic NO, window 0xc0002b,
state VisibilityUnobscured
UnmapNotify event, serial 10, synthetic NO, window 0xc0002b,
event 0xc0002b, window 0xc0002b, from_configure NO
LeaveNotify event, serial 10, synthetic NO, window 0xc0002b,
root 0x26, subw 0xc0002c, time 3153248789, (1341,529), root:(1341,529),
mode NotifyNormal, detail NotifyVirtual, same_screen YES,
focus YES, state 0
KeymapStateMask appears to control the Keymap/Unmap events and mozilla doesn't
catch them
tk nsAppShell does anything about event masks.
the xlib port a long time ago
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/widget/src/xlib&command=DIFF_FRAMESET&file=nsAppShell.cpp&rev2=1.38&rev1=1.37
did think about that event but does not any longer
http://lxr.mozilla.org/seamonkey/ident?i=ALL_EVENTS
#gtk+ said i might use gdk_window_add_filter to get gtk to tell me about the
event, but i'm not sure how (i don't have gtk experience or books).
blizzard was pointing me to toplevel_window_filter, which will be useful if i
can get gtk to pass the event along.
And of course, there's the question, do we want to use the *map events or the
Enter Leave events which actually have focus as a parameter.
Comment 25•23 years ago
|
||
Tracking the window focus with and without a window manager is quite hard; you
have to watch both focus in/out events and also certain crossing events.
GTK+-1.2.10 uses an algorithm taken from Xterm to do this; it has many
years of testing, I checked it and it makes theoretical sense, and seems
to work in practice. If at all possible, you should simply take advantage
of the GDK focus-in/focus-out events on the toplevel, rather than doing
it yourself.
Perhaps this is one of those chasing-your-tail bugs, where code was put
into Mozilla to work around problems in GTK+ (GTK+-1.2.9 didn't work
right without a window manager) that then broke when GTK+ was fixed?
Comment 26•23 years ago
|
||
This code was put in place so that you could track focus availablity for not
only toplevel windows but toplevel windows where mozilla was in a gtkplug (
nautilus. )
If Mozilla's focus model was actually fixed to work correctly this wouldn't be a
problem.
Comment 27•23 years ago
|
||
Comment 28•23 years ago
|
||
Owen: that code is in there so we can properly set focus to ourself, even in a
plug/socket. If we don't do it by hand we don't always get the toplevel focus
in focus out events because the toplevel in a plug/socket is the plug.
The patch I just attached seems to work without a window manager in Xnest.
Thanks to David Olsson who pointed it out to me. I always thought that you
would get FocusIn/FocusOut events.
I'm looking for testing, review and feedback.
Updated•23 years ago
|
Whiteboard: [wgate] → [wgate] have patch; need testing; r=? sr=?
Comment 29•23 years ago
|
||
Well, comparing to the code in GTK+-1.2 CVS (basically, what's in 1.2.10)
I think you'll get spurious multiple focus in / multiple focus out.
If you are OK with that, then it probably will fix your problem.
I guess what you are saying is that you don't want to track focus -
since plug/socket will give the child focus when focus is within it -
you want to track "toplevel activation"?
The XEMBED spec that GTK+-2.0 uses does include activation as well
as focus, though it isn't revealed in the GTK+-2.0 interfaces, because
GTK+ doesn't have such a concept, so with some hacks (snooping the
XEMBED messages?), you may be able to do this a bit more reliably
in GTK+-2.0.
Comment 30•23 years ago
|
||
I didn't see any spurious messages when I was testing but I might have missed
it. Where should I be looking in the gtk code for the example that you are
using as a reference?
As for Gtk+-2.0 can we add something at this point or is it too late?
Comment 31•23 years ago
|
||
No joy.
Tried the patch with a bare X session (replaced the fvwm95 with xterm in
.xinit). Could not type characters into text widgets.
> gtk12-config --version
1.2.8
Comment 32•23 years ago
|
||
I tried mine in XNest. Worked there.
Comment 33•23 years ago
|
||
What GTK version? Could you try with a bare x server? (xnest probably should
use you normal x setup including WM, I imagine - it's not installed on my
system). Try editing your .xinit temporarily to replace your WM with xterm.
Comment 34•23 years ago
|
||
[blizzard@face blizzard]$ rpm -q gtk+
gtk+-1.2.10-11
I'm not using a WM in XNest which, as far as I know, should work as an X server.
I can try a bare X server, too.
Comment 35•23 years ago
|
||
The other possibility is that the code has some sort of dependency on the gtk
version.
I ran Xnest on a RH7.1 box with gtk 1.2.9. The patch appears to work there.
With gtk 1.2.8 and the same Xnest (running from a BSD box with the display going
to the RH Xnest session) it does not work. So I think the patch works with gtk
1.2.9 and above. That's good, but not great. It does happen to solve my
problem.
Comment 36•23 years ago
|
||
I wonder why this is gtk version dependent. Doesn't make any sense to me.
Comment 37•23 years ago
|
||
Note that the 1.2.8 gtk box was BSD XFree86 3.3.6, and the 1.2.9 gtk box was
linux probably Xfree 4.x (though the Xfree version shouldn't matter).
I have a 1.2.9 gtk BSD box, I'll try that tomorrow. Perhaps the version is a
red herring.
Comment 38•23 years ago
|
||
0.9.6 is out the door already.
Comment 39•23 years ago
|
||
*** Bug 111448 has been marked as a duplicate of this bug. ***
Comment 40•23 years ago
|
||
i'm also seeing this with afterstep. i did some testing with xnest, and without
a windowmanager i cannot type any keyboard input to the browser. however when i
start afterstep in xnest everything seems fine?!
i'm not sure why it would not work outside xnest, and then work -inside- xnest
Comment 42•23 years ago
|
||
From bug 111448 (duped to this). Raising to 'normal' since this affects use
with a real WM (and embedded use may not have a WM). I'll re-check the patch.
The same GTK that comes with redhat 7.1 and 7.2. In 7.2 it's
libgtk-1.2.so.0.9.1, mozilla is "Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:0.9.2.1) Gecko/20010901"
The problems is with the transient windows only, and only if they don't get
reparented. In twm that behaviour can be changed with DecorateTransients witch
forces reparenting. Otherwise the windows only get a simple frame around them,
allowing you to move/resize/iconify/whatever, but they won't get a title and
won't be reparented, as if running without a window manager.
If I apply the NoTitle option to some of the windows, forcing twm to not draw a
title, only the frame as before, but still reparenting the window, the focus
works perfectly well.
Other window managers allways reparent windows, so the problem won't arise.
Severity: minor → normal
Comment 43•23 years ago
|
||
see Bug 78928, comment #42...
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 44•23 years ago
|
||
I start mozilla 20020408 without wm, on redhat 7.2 with gtk+-1.2.10-11,
seems the mozilla window get the focus because some shortcuts work (for example
Alt-Q) but I cannot type in the location text area.
I see it works fine with netscape 4.7, I see this while replacing old netscape
with latest mozilla in kiosk application.
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Comment 45•23 years ago
|
||
I tried applying the patch to mozilla 2002060405 on a redhat 6.2 system.
To reproduce the bug I use use twm without DecorateTransients and without
DecorateTransients and without NoTitleFocus. The test: make sure that I can
type into a dialogue box (e.g., the text box that pops up when you edit
preferences.)
Results: with gtk+-1.2.6-1 (most recent update for redhat 6.1) the bug still
manifests itself
I installed gtk+-1.2.10 (recompiling it from source, which required installing a
freshly compiled glib-1.2.10 and glib-devel-1.2.10). The bug went away.
Apparently, it is dependent on the gtk+ version.
Comment 46•23 years ago
|
||
It looks like we have confirmation that a later GTK "fixes" things so the patch
works.
We should at least get the patch in, and if possible see if we can solve why it
doesn't work with earlier versions of gtk.
Nominating for 1.0.2/1.2 (there's no 1.0.2 keyword yet, so I used 1.0.1)
Keywords: mozilla1.0.1,
mozilla1.2
Target Milestone: mozilla0.9.9 → ---
Comment 48•23 years ago
|
||
*** Bug 163102 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 49•22 years ago
|
||
This bug is blocking the "Make 1.0.2 not suck" bug :
<URL:http://bugzilla.mozilla.org/show_bug.cgi?id=161807> .
Is the october 2001 patch fully tested yet ?
Comment 50•22 years ago
|
||
Have you tested it, XandreX?
Comment 51•22 years ago
|
||
I have been looking at this and in /widget/src/gtk/nsWindow.cpp
function: void nsWindow::HandleMozAreaFocusIn(viod) has a test for if mozarea
already has focus. nBlockMozAreaFocusIn never is PR_FALSE if no wm is running.
Maybe a connection with DispatchSetFocusEvent
ofending conditional at lines 1537, 1538 :
if (nBlockMozAreaFocusIn)
return;
Remove the Offending Conditional and moz will recieve the keyboard focus. No
more focus events seem to be triggerd with or without this test.Tested on 1.0.2
but the code is the same in 1.0.0 and 1.3a so looks like maybe and end to this
bug? Tested on gtk and glib versions 1.2.8, 1.2.10
Comment 52•22 years ago
|
||
I tried removing these few lines from nsWindow.cpp, it makes things a lot
better. However, it doesn't fully fix it. Text fields (at least) are still
broken.
I applied the previous patch, too, but it doesn't change things.
Try the following:
1. Open Mozilla.
2. Load a page by selecting a bookmark with mouse.
3. Open new window with C-n.
4. Load a page from bookmarks on new window.
5. Activate location text field with mouse.
6. Try to move the cursor with arrow keys. Ooops...
I guess the relevant software is Mozilla 1.3a, GTK 1.2.10, Debian Woody, XF
4.2.1 and WindowMaker.
It works fine if sliding focus is turned on, as before... This probably has
something to do with interpreting of focus events only.
Comment 53•22 years ago
|
||
Oops, the location text field must be activated on older window. Otherwise it
works as it should and the bug doesn't show up.
And the Mozilla version was 1.3b, not 1.3a.
Comment 54•22 years ago
|
||
Activating window before sending events seems to fix the problem. This ugly hack
makes WindowMaker focus the window before sending any button pressing events. I
found no ill effects in about one minute of testing. :) I don't know how hard
finding and fixing this bug might be, but apparently "fixing" the problem
elsewhere seems to be trivial. WindowMaker is Debian-packaged version 0.80.1-6.
--- ../wmaker-0.80.1.orig/src/event.c Sat Mar 15 00:43:40 2003
+++ src/event.c Sat Mar 15 00:39:45 2003
@@ -656,6 +656,7 @@
static void
handleButtonPress(XEvent *event)
{
+ WWindow *wwin;
WObjDescriptor *desc;
WScreen *scr;
@@ -663,6 +664,11 @@
L("got button press");
#endif
scr = wScreenForRootWindow(event->xbutton.root);
+ wwin = wWindowFor(event->xcrossing.window);
+
+/* printf("%p",wwin); */
+ if ( wwin != NULL )
+ wSetFocusTo(scr, wwin);
#ifdef BALLOON_TEXT
wBalloonHide(scr);
Comment 55•22 years ago
|
||
This may help to track it, as it seems to be related.
Something funny happens also:
If I click on a menu, the menu popsup, when I move the cursor over to the menu
next to it, no menu will popup, but its entry will appear clicked.
This is with mozilla 1.4 on RH 9, but I dont thing X version matters much.
Comment 56•21 years ago
|
||
Blizzard, how about requesting review on this change?
Comment 57•21 years ago
|
||
*** Bug 219369 has been marked as a duplicate of this bug. ***
Comment 58•21 years ago
|
||
Just to keep this alive: this bug still happens on Moz 1.3/1.4 with no WM. My company was
hoping to run Moz in a no-WM kiosk-style mode but we're forced to use a WM until we can find
a way around this problem.
Comment 59•21 years ago
|
||
Still fails on Moz 1.4 / FreeBSD 5.1 with twm or no wm.
I have tried all the suggested patches for this bug and for bug 78928
with no luck.
twm users: a workaround is to use the f.focus function in twm.
I may be able to come up with a patch for twm, but I think the basic problem
is in moz (or gtk), given that using no wm has the same symptoms.
Comment 60•21 years ago
|
||
In fact the cleaner way to solve this in TWM is to enable DecorateTransients
You can than undecorate them anyway if you wish using the NoTitle list.
The difference with this is transient windows (WM_TRANSIENT_FOR property) get
reparented. By default transients are neither decorated nor reparented.
More modern window managers reparent every window. This is a choice, not a bug
in twm. TWM needs no patch, only perhaps a new property: ReparentTransients,
witch would do the same as DecorateTransients while avoiding the decoration.
Comment 61•20 years ago
|
||
veru much annoying (I was using it as a kiosk-browser) but I got an idea and
checked it with a wm. It seems like its the Form autocomplete that removes focus
from input field, so a user_pref("browser.formfill.enable", false); in user.js
remove that and now I run it without problems and no wm.
Comment 62•20 years ago
|
||
OpenBox WM has the same symptoms:
https://bugzilla.icculus.org/show_bug.cgi?id=1053
(In reply to comment #59)
> Still fails on Moz 1.4 / FreeBSD 5.1 with twm or no wm.
> I have tried all the suggested patches for this bug and for bug 78928
> with no luck.
>
> twm users: a workaround is to use the f.focus function in twm.
> I may be able to come up with a patch for twm, but I think the basic problem
> is in moz (or gtk), given that using no wm has the same symptoms.
Updated•15 years ago
|
QA Contact: trix → events
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Comment 63•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: blizzard → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•