270971 - Keyboard focus stays on other Window, CTRL-W closes other window's tabs (keyboard virtual desktop switching suspected)

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Rob]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I suspect it has something to do with me using my keyboard to switch between
virtual desktops.  I've tried using OpenBox and MetaCity.  It's hard to reproduce.
I normally use the Windows Menu key to go to the next desktop, and Shift-Menu to
go to the previous desktop.  When I removed those keybindings and forced myself
to use the mouse, the problem all but went away.  It still happened
occasionally, I think because I use Super-L+Mouse4/5 sometimes also.  It will
happen in 100% of Mozilla/Firefox sessions if I wait long enough.

Other symptoms include not being able to focus keyboard in the current Window
(location entry, search entry, any forms on page).

I could speculate that Mozilla is registering a key being pressed, then the
Window manager switches, and Mozilla doesn't register the key being released,
and is in an odd state.

New windows always get focus.

I'm usually unable to get focus again on the Window, and have to close all tabs
in the Window and the Window itself.  Sometimes this means losing data
(unsubmitted forms).

I think that a reasonable catch-all solution would be that before keyboard input
is accepted by a particular Window, it checks that it has the WM focus, and not
another Firefox/Mozilla Window.  If another does, then it should change the
keyboard focus to the window with the WM focus.  This should probably be
temporary, and produce an STDERR alert.

Reproducible: Sometimes
Steps to Reproduce:
1.
2.
3.

Comment 1

[Rob]

After applying the following patch to openbox, I'm noticing the problem less,
but still sometimes.

http://www.topfx.com/dist/openbox-mozilla.patch
Patch comment: "assume a window does NOT take input if it doesnt specify as in
the case of mozilla for example"

Comment 2

[Bruce Keeler]

I get this too, using sawfish as my window manager.  Other symtoms include new
tabs being opened on the wrong window (when opened with Ctrl-T or Ctrl-Mouse2).

Surely it can't be too hard to figure out which window has focus?

Comment 3

[sampo.peltonen]

I have this problem occasionally too. For example ctrl-t really opens new tabs
in another the window located in another virtual desktop. Additionally, when
that happens, I'm also incapable of focusing (getting the cursor visible) into
address bar, google search textbox and find textbox. Although all other mouse
actions work ok. I can make it work again by popping out Firefox about box and
closing it. After that the everything works again. This bug bothers me several
times a day, but I don't know how to really reprocude it.

Comment 4

[Andrew Pimlott]

I have observed the same problem, using every version of mozilla I can remember,
as well as Firefox 1.0.  I am running Debian GNU/Linux unstable (mozilla-firefox
package 1.0+dfsg.1-1) with fvwm as my window manager.

I can reproduce the problem easily:
1.  Start firefox.
2.  Press Ctrl-N to open a new window.
3.  Using a window manager shortcut (for me, alt-tab), switch to the first
    firefox window, and back to the second.
4.  Press Ctrl-L to go to the location bar.  Observe that this seems to have
    no effect.
5.  Type, eg, google.com.  Note that these letters don't appear in the
    location bar, but the auto-complete pop-up appears.
6.  Hit enter.  Note nothing happens in this window.
7.  Switch to the other firefox window.  Observe that google is loaded.

This is a pretty annoying problem, which I haven't reported only because I
didn't know whether it was mozilla or my window manager.  I will be very
grateful to whoever can fix it!

Comment 5

[Joel Hoffman]

Is this the same problem as bug #223974? I frequently have this problem when
running Sawfish, but I do not remember experiencing it on my other computer in KDE. 

Comment 6

[Markus Vuori]

I have Fedora Core 3 and Openbox3 as window manager. I suffer from this problem
daily, and sometimes firefox refuses to read keyboard even if there's only one
firefox window open. But usually this is a problem only if I've multiple firefox
windows (eg. view source) opened. This bug is very annoying and I hope this will
be fixed soon.

Comment 7

[Markus Vuori]

I just noticed that I can reproduce this bad behaviour quite easily by clicking
view source and immediately after that (using my window manager keyboard
shortcut) changing to different desktop/workspace. After the view source window
has opened into another workspace and I switch back to my main firefox window in
the original workspace, the "view source" window has keyboard focus while the
firefox main window doesn't notice any keyboard activity. And really, situation
can be fixed by clicking Help->About->OK.

Comment 8

[Oleksiy Melnyk]

Thunderbird have the same behaviour(open "New Message", switch back, try to
MarkAllRead by pressing "Shift+C" - all "C"'s goes to "Compose" window), so it
is likelly not a Firefox's but a some common library's bug.

Comment 9

[Max Anastasio]

Same problems here too, several times a day.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Enviroment: Fedora 2 / Metacity
It happened randomly on past versions and also while using WinXP or Win2K with
virtual desktops, though, since i've been using Mozilla (Suite).

- CTRL-T and CTRL-W open and close tabs on a different window, usually on
another desktop;
- pressing CTRL-A & CTRL-C selects and copies text from the Other Window;
- can't type in the address bar / search box / form fields (can't even focus,
actually).

ALT-F4 works, luckily - as it seems to be the main solution, also if in some
rare cases just a couple of clicks on the page's body gives focus back to the 
window.
I've also tried to reproduce the problem following the steps described by Markus
and Andrew but neither worked for me... all I can say for sure is that it
usually happens just after I switch desktop.

Comment 10

[Daniel Ceregatti]

This is one of the reasons I stuck with a gtk1 compiled mozilla for so long. I
simply could not live with this bug. But then the genpoo people removed the gtk1
use flag for compiling mozilla (I presume because mozilla itself stopped
supporting it) and I was forced to gtk2. Well, by then the other bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=217639) that REALLY **** me off
was fixed so I decided to stick with the gtk2 version.

But then this bug was still there. It's been here for a LONG time. And it
remains to this day.

So I guess the point of this post it to say that perhaps gtk2 has something to
do with this. I've discussed this with a few other developers who've claimed
gtk2 does indeed have focusing issues.

BTW, isn't 9 (now 10) comments on a bug enough to elevate it from UNCONFIRMED?

Comment 11

[Andrew Pimlott]

Since I confirmed this bug in an earlier comment, I would like to report
that I have not observed this problem in my current version of firefox, nor
can I reproduce it using the steps given earier.  I am using package version
1.0.4-3 from Debian unstable.  As there has not been any activity on this
bug, I wonder if it is a fluke.  Do other people still experience the
problem?  I am using FVWM 2.5.12-5, which I think is very close to the
version I was using before, so I doubt it is a window manager change that
fixed things.

Comment 12

[Daniel Ceregatti]

I can asure you the problem still exists, as I live with it every day on two
machines. Changing WMs has nothing to do with it, as I've tried 3 different WMs
(and even 2 different distros) and the problem persists. Needless to say, it's
very annoying. 

Comment 13

[Daniel Erat]

I believe that this has been fixed in GDK, as described at
http://bugzilla.gnome.org/show_bug.cgi?id=109246 .  I no longer experience this
problem in Firefox since upgrading to the libgtk2.0-0 2.6.4-3 package in Debian
unstable.  I believe that the fix made it in to Sarge as well.

Comment 14

[Andrew Pimlott]

woo hoo--mozilla developers ignored the bug and it went away!  The system works!

Comment 15

[Rob]

Unfortunately I can't concur.  I have upgraded to the latest GTK package in
Ubuntu Breezy (GTK 2.6.8-1ubuntu1) and the latest firefox in Breezy
1.0.4-1ubuntu3, and I still encounter the same problem.  I am still able to
replicate this by using the keyboard to switch between virtual desktops.  The
sequence I use is as follows:
  1. Open new firefox.
  2. Press CTRL-n for a new Window, then before the new window opens...
  3. Use keyboard shortcut (in my case: Menu) to switch to next workspace.
  4. New Window appears ok, I can type in it and it has focus.
  5. I switch to previous workspace (Shift-Menu), and the firefox Window has
half focus again.

If I use the mouse to switch between workspaces, I do not have this problem.

I am unable to say whether any of the other focus problems are fixed - only that
my particular case (when using the keyboard to switch between workspaces) isn't.

I am still using Openbox (unpatched Ubuntu 3.2-7 version).

Comment 16

[Daniel Ceregatti]

I'm hoping that by posting to this bug, that I can bring it to the forefront. This issue is most definitely NOT fixed.

I think the problem stems from a combination of window manager, use of a pager, and perhaps even Xinerama.

I run the latest firefox and thunderbird (both 1.5 at this time) in Linux, and this keyboard focus issue is starting to become a real showstopper for me. This issue has been present since I switched from gtk1 mozilla to gtk2 mozila, and continued to my switch to ff/tb. This was well over 1 year ago.

As described in this bug, the problem is that the ff/tb window that has the window manager focus has the mouse focus, but not the keyboard focus. I can see that the window has the window manager focus by seeing that the window dressing are that of a focussed window, and I can click on widgets such as drop downs, which work, but when I use the keyboard, the typed characters or keyboard actions appear/happen in the previously focussed ff/tb window.

This doesn't happen all the time. It takes a while for both ff/tb to reach this state, but once it starts, it remains until I exit. Usually when the problems start, I end up exiting and restarting to make the problem go away.

I experience this problem on both my home and work machines, which are both gentoo unstable (~), running the latest and greatest Gtk and glib (2.8.9 and 2.8.5 respectively), running nvidia's "Twinview" which is "one frame buffer powering 2 display devices", with openbox. Twinview provides Xinerama information, and behaves in exactly the same way a machine with two cards in Xinerama mode would. The one difference between my home and work machines is my home machine is x86_64.

The gtk based Eclipse program also had this problem on both my machines. It seems they were able to fix it, or work around it. I've spoken with an eclipse developer, one [e-mail],  who acknowledged the problem as being in gtk (or glib, I don't quite recall), and that eclipse had code in place to work around it.

I've contacted the eclipse developer and I'm hoping to post links to their bugzilla regarding this issue in subsequent posts to this bug.

Can someone please re-visit this bug?

Thanks,

Daniel

Comment 17

[Billy Biggs]

Eclipse had problems relating to windows not receiving focus events from
GDK in certain (complex) situations involving override-redirect windows,
and keyboard grabs (as happens when a window appears announcing your
virtual desktop when switching using a modern window manager).  These
seemd to be caused by the GDK bug mentioned earlier:

  http://bugzilla.gnome.org/show_bug.cgi?id=109246

This was fixed for GTK+ 2.6.8 and Eclipse 3.1.1 disables its workarounds
if we detect at least version 2.6.8.  However, I do not know of any bugs
about keyboard events going to the wrong window.

If you're using GTK+ >= 2.6.8 I am afraid I have no new advice.

Comment 18

[Daniel Ceregatti]

I've recently discovered the source to this problem (for me, at least). Openbox. I decided I had enough of this issue, as it has plagued me for a long when using firefox, thunderbird, eclipse, and a few other gtk2 apps. After extensive trial and error, I discovered this problem simply does not exist in other window managers. I moved to XFCE a few months ago and the problem has entirely gone away.

Hope this helps.

Daniel

Comment 19

[Joe Smith]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111312
Ubuntu Gutsy Gibbon 7.10

I followed the steps in Comment #4, and did not have any issue with the incorrect window being selected.

Comment 20

[Kevin Brosnan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007120404 Minefield/3.0b2pre ID:2007120404

comment 4 and comment 15 both work for me

Comment 21

[Wayne Mery (:wsmwk)]

is there consensus that the problem here is (or was) openbox, and not mozilla? Ditto fvwm?

Comment 22

[Kevin Brosnan]

No one has come forth with new info. Closing this as worksforme. If someone can reproduce something similar a new clean bug would be best.