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?

dup of bug 73727 ?

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.

Obviously Mozilla is in good company, "StarOffice" is said to behave the same way.

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

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.

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!

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.

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.

QA contact updated

*** Bug 91446 has been marked as a duplicate of this bug. ***

*** Bug 78562 has been marked as a duplicate of this bug. ***

*** Bug 93637 has been marked as a duplicate of this bug. ***

*** Bug 94565 has been marked as a duplicate of this bug. ***

counting dupes of dupes and dupes of the twm relatives marking mostfreq

*** Bug 98163 has been marked as a duplicate of this bug. ***

*** Bug 96847 has been marked as a duplicate of this bug. ***

Moving out.

*** Bug 105147 has been marked as a duplicate of this bug. ***

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)

Track the focus events in gtkmozarea.c and see if they are being properly delivered.

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.

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?

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.

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.

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.

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?

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

I tried mine in XNest. Worked there.

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.

[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.

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.

I wonder why this is gtk version dependent. Doesn't make any sense to me.

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.

0.9.6 is out the door already.

*** Bug 111448 has been marked as a duplicate of this bug. ***

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

0.9.6 is long gone. -> 0.9.7

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.

see Bug 78928, comment #42...

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.

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.

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)

I'd rather see this bake on the trunk for a while.

*** Bug 163102 has been marked as a duplicate of this bug. ***

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 ?

Have you tested it, XandreX?

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

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.

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.

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);

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.

Blizzard, how about requesting review on this change?

*** Bug 219369 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

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.