Open Bug 228646 Opened 22 years ago Updated 9 years ago

keyboard focus randomly lost and cannot be regained except by opening menus with mouse

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: lkcl, Unassigned)

References

Details

(Whiteboard: [SmBugEvent])

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 suddenly and unpredictably after usage of mozilla (multiple tabs and windows) and flicking to other applications, the keyboard focus is lost. no data can be typed into any keyboard input boxes. the cursor does not appear (sometimes). when i say any keyboard input boxes i mean ALL input locations: the URL entry box, any form input boxes. i also mean that keyboard shortcuts don't work, either, such as ctrl-q, ctrl-w, ctrl-n etc. occasionally, data _can_ be typed but in textareas (such as the details box i am typing in now) the cursor keys and backspace fail, and the mouse has to be used to highlight text (which also sometimes doesn't work) and overwrite. the only way to recover fully is to quit mozilla. a partial recovery can _sometimes_ be achieved by going to the file menu, selecting "open location" and typing in a random URL. _sometimes_ after this action is performed, the keyboard focus _may_ be regained. careful examination of the web pages sometimes shows what the hell is going on. pressing tab gives a clue. by pressing tab, the keyboard focus can be noted to have shifted sometimes down to the status bar (????!) because some of the contents of the status bar get a dotted line-box around them (???!) sometimes, also, the keyboard focus flips to url and other boxes _on the page_. by pressing the first letter of some of the urls and other boxes on the page, a dotted line-box goes around those urls or other boxes, where the letter pressed is the same as the first letter of the thing being highlighted by the dotted line-box: repeatedly pressing that letter cycles around all urls or boxes with that first letter. [btw as i type this, i have flicked to another window and returned to it and have lost the ability to use cursor keys and delete]. Reproducible: Always Steps to Reproduce: 1. run mozilla. 2. open some windows and tabs, making sure that the keyboard shortcuts are used. 3. open some other applications. 4. browse a bit. enter some data on forms using tab not the mouse to move between form entry boxes. 5. add some more tabs and windows at random, again using ctrl-t and ctrl-n not the mouse. modify some of the url locations using a combination of mouse and keyboard actions. 5. flick to other applications a bit (use fvwm because it has multiple windows) 6. flick between mozilla windows using alt-tab (in fvwm) not the mouse. 7. repeat until failure, which may take 5 mins, it make take 50 mins, but it will definitely happen. okay, also, try this: 1) open two windows, one with a dialog box on it (like the enter_bug url). 2) select the second window. 3) click on any text in the page NOT on a URL 4) type a letter, any letter, and watch what happens. keep repeating a few other keys: URLs are selected, text is highlighted. 5) return to the first window and try to type into the dialog box. try pressing delete. Expected Results: 1) keyboard focus should be returned correctly when selecting a window or a tab. implementation-wise, a per-window and per-tab keyboard focus tag needs to be maintained: i don't know what you have now, but if you have a single bit of state information and "endeavour" to return the focus "somewhere" that's definitely not going to be sufficient. 2) delete and cursor keys should work! i'm classifying this as a "major" bug because it causes mozilla to become unuseable. loss of keyboard usage is like... well... the use of a keyboard's like... a major feature of input to a web browser!
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031211 I noticed that sometimes while typing comments in bugzilla typing stops, and I can´t copy&paste, and I can only use the mouse to position the cursor. Once, when I did SelectAll in the LocationBar, SelectAll was applied to the content of a neighbouring tab. As I saw it rarely outside this comment box, and I´m scarce on memory, both RAM and harddisk, I didn´t want to file a bug before I saw steps to reproduce.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
*** Bug 226994 has been marked as a duplicate of this bug. ***
Similar or same problem here (Mozilla + KDE). Workaround: switching tasks using ALT-TAB always helps.
I think this is the single greatest problem I have with Mozilla (and Firebird). It's been around for a long time, and with each release I've waited with baited breath for it to not show up (a dangerous proposition...) Like the first poster, I can find no quick way of producing the bug, but if I use the browser long enough, it _will_ happen. A variation on the above workaround is to use the mouse to open File | Open File and then hit the escape key. Sometimes, this will restore keyboard interaction, sometimes not. Problem occurs under at least the Debian and Gentoo distributions of Linux.
I can confirm this bug under PPC Debian Sarge, Mozilla ver. 1.5 It's a sporatic hassle; I wish I could fix it.
(In reply to comment #2) > *** Bug 226994 has been marked as a duplicate of this bug. *** I'm not quiet sure if this is really a duplicate of bug 226994. I got the same problems described in bug #226994 when I'm surfing on a specific site (of our company which isn't publicly available). But I can definitely use the backspace although I can't move within a text input field using the cursor keys or Home or End. Because I only got this problem after using one specific homepage I started thinking it might have to do something with CSS or JavaScript. By the way: I'm using Mozilla 1.7.2. Mostly under Windows XP Professional (shame on me, I know).
Product: Browser → Seamonkey
requested information earlier today: still see this SM problem? answer: i've not re-encountered the same issue - keyboard focus still remains a major [reliability] issue however not to the same extent as described in this bug report. also, i've not done as extensive testing, either. keyboard focus is still definitely stolen - and lost - occasionally. e.g. ctrl-L only working when you click actually in the url bar, that sort of thing. version: 2.0.0.14
I still see this in SeaMonkey/2.0a1pre (currently Mozilla/5.0 (X11; U; Linux i686; rv:1.9pre) Gecko/2008060301 SeaMonkey/2.0a1pre) Focus is sometimes stolen by other tabs (i.e. all keyboard commands go to a tab not currently in view) and could not be regained until the click on the current tab. Fedora 8 + XFCE 4.4.2
I too have this problem with keyboard input. A very easy way to reproduce it is to use Facebook chat. When I try to chat in Facebook, keyboard input ALWAYS stops responding the moment I receive a message. The workaround (and a quite annoying one at that) is to click on the Windows taskbar then back on the chat text input box. I also had this problem intermittently on http://imo.im, workaround is the same. Click anything that's not Firefox then click again on text input box. I am running Windows 7 but I have had this problem since XP SP2 in 2007.
This sounds to me as if some hothey had been inadvertently depressed, moving the focus or otherwise triggering some JavaScript, but which hotkey? The browser defines quite a lot of them (the one which trips me most often is the Tab key, which of course moves focus out of the current input area rather than inputting a hard tab), and web pages may also define any number of additional ones. Alas, without an exact description of what happened (on which page, and hitting which key, or at least within which group of "not too many" keys), this problem is extremely hard to diagnose. Web-chatting itself may involve time-critical sequences since the page has to display incoming messages (possibly stealing focus to do so) and also accept outgoing ones. The mentioned workaround moves the focus out of the browser then at a well-defined spot into it which seems to indicate that focus has somehow been swept away by the webpage while the user was typing. Related with bug 78414 ? Has this bug ever been seen on static pages (with no moving content, no auto-refreshes, etc.) ?
Whiteboard: [SmBugEvent]
(In reply to comment #10) > This sounds to me as if some hothey had been inadvertently depressed, no. > moving > the focus or otherwise triggering some JavaScript, but which hotkey? zero hotkeys. > The > browser defines quite a lot of them (the one which trips me most often is > the Tab key, which of course moves focus out of the current input area > rather than inputting a hard tab), and web pages may also define any number > of additional ones. > > Alas, without an exact description of what happened (on which page, absolutely any page. > and hitting which key, absolutely any key. > or at least within which group of "not too many" keys), > this problem is extremely hard to diagnose. Web-chatting itself may involve > time-critical sequences since the page has to display incoming messages > (possibly stealing focus to do so) and also accept outgoing ones. The > mentioned workaround moves the focus out of the browser then at a > well-defined spot into it which seems to indicate that focus has somehow > been swept away by the webpage while the user was typing. ok that's the kind of speculation which i believe may lead somewhere. the unfortunate thing is that it literally occurs - occurred - completely at random, taking sometimes several days for the bug to manifest. i've since stopped opening over 100 tabs across multiple windows (recent firefox builds eats far too much memory to make it practical: i've seen 2.5gb i.e. total consumption of all memory and all swapspace...) so have not encountered this bug since. if indeed it's related to long-term usage of firefox with over 100 tabs and multiple windows. > Related with bug 78414 ? Has this bug ever been seen on static pages (with > no moving content, no auto-refreshes, etc.) ? yes.
btw before i forget: i am still seeing occasional failure of cursor keys, accompanied by failure of the cursor "blink" mechanism. this is *different* from the above-reported bug. this particular bug usually occurs with gmail, when the machine running firefox happens to be under particularly heavy load. also, significant long-term usage is also required to replicate this particular bug, as well as significant memory leakage (1gb+). but, i repeat: this is NOT the same thing as the reported bug, because only cursor keys were affected (not *all* keys).
(In reply to comment #10) > Related with bug 78414 ? hard to tell. that bug indicates loss of function of ctrl-w and ctrl-q. this is *total* loss of *all* key input - not just into the browser itself but even loss of keyboard shortcuts for menu functions, which are nothing to do with the xulrunner engine. l.
btw 226994 is *not* the same as this bug. see comment #12.
When I experience this (I think I am experiencing the same bug), I find that there is always another tab or window that has the Mozilla keyboard focus, and destroying that tab restores my ability to get the focus where I want it by clicking. A better workaround that works I have tried at least once is to create a new tab (which I default to about:blank), move the new tab to a new window, and then destroy the new window. I have observed this problem on GNU/Linux Ubunutu-x86_64 14.10 (and probably earlier versions), in an environment running mostly Gnome user interface applications.
I think I am experiencing something similar on Fedora 22 with firefox-40.0-4.fc22.x86_64. For me I always have two windows up, one of them normal and one of them is a private window. When this happens for me I can never get keyboard focus in one of the windows, but in the other window (the one where the focus is locked) I can see my characters that I am typing even though my mouse is focused on the other window. In other words the input from the keyboard is going to the wrong window. This happens about once every few days and the only way to get rid of it is to completely close all of the tabs from one of the windows. I usually close all of them from the window that is experiencing the problem so I don't know if it works the other way (if I close all of the windows from the tab that is not experiencing the problem). Let me know if I can help with more information.
Same issue as Dusty here. I'm running Fedora 22 with firefox-42.0-2.fc22.x86_64 and I've had this issue happen multiple times today already. I've been using Chrome up to this point, so it was never an issue. I'm also running the i3 window manager. Both windows are normal. I can click/scroll/select with the mouse in the second window, but clicking on text boxes does not bring focus and anything I type shows up in the first window only. Moving tabs from the window that can't focus to the window that can allows me to focus/type in those tabs. I just discovered that opening a third window seems to reset this behavior and lets me select any of the three. Upon closing the third window, I can select either window, but then it goes back to not being able to focus on the other window again.
I discovered the 3rd window trick a while back and have been using that. Frustrating, but it is at least something.
Right after commenting, I actually discovered that if I move one of the windows to a different workspace and then back, the problem goes away (for a while, at least). The 3rd window trick also apparently only works if it's in the middle of the two. If I move it to the left or right, it goes back to being a problem. I'm using i3 (tile based window manager), so my new "fix" may be a bit different if you're not. I've noticed application's behavior in i3 can be a little wonky sometimes.
I switched to using the nightly version of firefox several months ago and have not seen this issue. I don't know when it was fixed but it seems to be fixed upstream.
(In reply to Adam J. Richter from comment #15) > When I experience this (I think I am experiencing the same bug), I find that > there is always another tab or window that has the Mozilla keyboard focus, > and destroying that tab restores my ability to get the focus where I want it > by clicking. > > A better workaround that works I have tried at least once is to create a new > tab (which I default to about:blank), move the new tab to a new window, and > then destroy the new window. I'm having the same problem every now and then and this is the only workaround I can use. Alt-Tabbing to another Firefox window or another application and back does not fix the problem. Window manager clearly displays that the focus is in the correct window so I guess Firefox is internally forwarding X events from the [window manager] focused window to another "logically focused" window. I do not know any easy way to reproduce it. Is there anything I can do once I hit the problem to help diagnose the issue? I can attach gdb to Firefox process on the fly if needed but I'm running release version without debugging info. I'm currently running Firefox 45.0 (build id 20160304114926). Also worth noting is that I'm hitting this same bug with Thunderbird 38.6.0, too. I'm getting into situation where the keyboard input switches to main Thunderbird window while I'm writing a new message in a pop up window about twice a week. That's even more problematic because Thunderbird uses single letters for actions (e.g. pressing "a" will archive currently focused message, "j" will mark it as junk). The focus switch to main window usually happens in the middle of sentence so I guess it's not related to window manager behavior. My guess is that the problem is caused by some kind of race condition while different windows are refreshing the display. Somebody suggested status bar activity above - does that code path touch any focus related events? I'd guess that the bug happens if some focus event is triggered while some keyboard button is hold down. Additional details: I'm currently running "marco" as my window manager but I have previously hit this with sawfish, compiz and cinnamon, too, so I guess this is not a window manager bug.
The problem may be triggered easier if you're running "unclutter". https://bugs.launchpad.net/ubuntu/+source/unclutter/+bug/1231588
You need to log in before you can comment on or make changes to this bug.