Closed Bug 70812 (keydead) Opened 20 years ago Closed 16 years ago
[meta] mozilla stops accepting keyboard input
I am not sure if it is acceptable for a simple user to create tracking bugs but anyway I think it might help since this kind of bug recently is frequently reported. So bug #30841, bug #60851, bug #68965, bug #69812 (unconfirmed), bug #70441, (unconfirmed) and bug #70484 seem to be related.
Let's restrict this bug to problems where Mozilla is usually supports some kind of keyboard input and does, but sometimes stops accepting it. This includes all of the six original dependencies except for bug 60851. (Bugs where Mozilla fails to support keyboard input at all are usually in the "keyboard navigation" component, or may have the "access" keyword.) Adding 70350,69506 and confirming. Sorry if I'm morphing your bug, but I think this is what you intended the bug to be.
thanks for creating this! I'm marking this moz 1.0, but that doesn't mean the dependant bugs won't be fixed :)
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Adding that mostfreq bug 54936 "Dismissing a dialog confuses the focus"
Depends on: 54936
Hardware: PC → All
Has anyone ever seen this in an embedded Gecko (WinEmbed, MFCEmbed, gtkEmbed, ...)?
Adding bug 76621, sidebar elements should not grab focus from other parts of window.
Depends on: 76621
adding self to cc: . only additional note is that changing focus in panes often seems to be the cause of this no further keyboard input for me in various situations.
Focus issue -> bryner
Assignee: alecf → bryner
Status: ASSIGNED → NEW
Is bug #76393 one of these?
with 67977 being a difficult issue to satisfactorally(sp?) resolve (IE doesn't get it "right" either) and 77621 being the only issues left open, I'm inclined to close this and just leave those two bugs standing. Aaronl, do you agree?
Chris, I'm fine with closing this - although I think 67977 is still worth fixing when someone comes up with a good solution.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Reopening due to the blocker bug 101239.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Er, I don't think we really need to reopen this bug every time a bug pops up that hangs the app.
Assignee: bryner → nobody
Status: REOPENED → NEW
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Is bug 90337 this as well?
Mozilla stops accepting keyboard input when i switch in mac os 9, from a open .htaccess-dialog to the finder.
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130 At several times I have lost the ability to type into forms as well. Ctrl-VCX dont respond either, but the menu's still work. Haven't seen typing into forms mentioned yet, so yeah it effects that too. Workaround has been to cut and paste until I can reload mozilla, although at least once or twice it has just started working again! Also, at times with multiple windows open, I can type into one of the Mozilla windows, but not into the forms on the other. I can't remember if changing tabs within the same window can produce this effect.
(To Jason Kennerly, and others) When keyboard input is lost, can you access the menus by keyboard? (Alt-F for File, etc.)? If not, it could be that, as sometimes happens, the Alt, or Shift, or Ctrl bit remained 'on' in the keyboard driver for some reason. The fact that you write "at least once or twice it has just started working again" made me suspect that. Try tapping each Shift, Ctrl and Alt key a few times, and see if the problem is gone. If so, this is a problem with the OS keyboard driver, and not with Mozilla. It can happen with any application. There could be other kinds of problems that are not Mozilla-specific. Whenever this problem occurs, try moving to other applications (does Alt-Tab work?) and see if the keyboard works there (and if it does, return to Mozilla and see if the problem is gone).
I'd like to report a bug that seems similar to those in this bug, but different in that keyboard input never works in popup dialogs (e.g. the find, address, and authentication dialogs. I get the same lack-of-keyboardability with: Linux/Mozilla 1.0 Linux/Mozilla 1.3b Linux/Mozilla build 2003022810 FreeBSD/Mozilla (don't remember version) I can cut-and-passte into the text boxes, but can't type. It's maddening, because otherwise I could use this fine browser for my day-to-day needs. Note that I have no troubles with form fields, or the static address bar at the top of the window. Only in popup dialogs (and in all popup dialogs) does the keyboard not work.
This seems the right place to add this comment: I'm using Mozilla 1.3 on Debian Linux (sid) (package version 1.3-3) with Window Maker 0.80.1 (package version 0.80.1-6). I experience, but can not reliably reproduce the problem in #20, however, when it does occur it is not a stuck metakey issue... if I paste something into the address bar (this triggers the "search google for..." dropdown) I can type freely into the address bar for as long as the dropdown is open. If I clear out the address bar or close the dropdown by clicking outside of it, input stops again. When input has stopped, I cannot type into the address bar or into the forms. It appears that Window Maker still has the keyboard input, since I can use the keyboard to change workspaces. Changing workspaces to/from the workspace containing Mozilla fixes the problem, sometimes.
surely having the browser repeatedly stop accepting keyboard input is worth assigning to someone? It's nearly completely unusable in its current state.
Target Milestone: mozilla1.0.1 → Future
Don't know if this helps, but whenever this problem happens to me, I'm able to make Mozilla accept keyboard input again by opening a new browser window and entering a bit of text in the address bar of the new window. Opening just a new tab in the existing window isn't enough, but after opening a new window, I can enter text again in either the original window or the new window. Unfortunately, I haven't been able to reproduce (yet) an exact sequence of steps that will lead to keyboard input being frozen. On the other hand, I've had it happen on a number of different platforms: MacOS X (Moz 1.4), Debian (Moz 1.4-4), and Gentoo (1.4-r3, on x86 and PPC). In each case, the 'open new window' workaround seems to allow keyboard input again.
-> Component's default owner ("Reassign[ed] bug to owner and QA contact of selected component")
Assignee: nobody → aaronlev5
Steps to reproduce: 1. Type text in Mozilla. Works fine. 2. Change vitual desktop. 3. Type something in a window in that desktop. 4. Switch back to Mozillas desktop. 5. No typing possible in Mozilla. I noticed that if I click on the desktop next to the browser and then click on some textfield in Mozilla, typing is possible again, no need to minimize. I use KDE 3.1.4 and Mozilla 1.4.
Have a Fix. Been working on this over at Gentoo Forums. One guy was using enlightenment 16.5 and firebird .7 . He fixed problem by: If you right click on the desktop and select focus settings, then change it from "focus follows pointer sloppily" to "focus follows pointer" that should fix it. Well at least in my case it did. I am running KDE and and Mozilla 1.4. Fixed it with: Went to Control Center/Desktop/Window Behavior/Focus Tab and Section. It was set to 'Click to Focus' and changed it to: Focus Follows Mouse. Maybe this will help the developers. Until then it works. At least so far haven't had they issue pop up. If anyone cares to look at the thread here it is: http://forums.gentoo.org/viewtopic.php?t=82782&postdays=0&postorder=asc&start=25
OOOPs, seems to minimize the severity, but not fix it completely. I just had it happend again. Had to ALT-TAB couple times and focus was back. May have jumped the gun a bit.
I've got the problem with mozilla-1.5 that I built on my gentoo box, but the problem doesn't show up with the mozilla-1.5 or 1.6b from http://www.scottbolander.com/mozilla-xft.html. (It took me quite a while to figure out that I wasn't running different versions of mozilla since MOZILLA_FIVE_HOME had been injected in my environment from the /etc/env.d scripts). Problem symptoms ---------------- The problem seems to be related to focus somehow (and different than the problem mozilla-1.4b had with the autocomplete ticking off the focus, which was fixed by 1.5): - starting a new mozilla window (and it doesn't matter wheter the cursor is in the window when it appears, and it doesn't matter whether this is the first mozilla window to appear), the cursor is in the location bar; - when I type the location bar doesn't seem to received the keyboard input: - if I click in it either - if I click in the display area (blank) and then in the location bar it still doesn't work; - if I exit the window and reenter it still doesn't work; - if I click in the location bar, exit the window and reenter it still doesn't work; - ahhAH! if I click in the display area, exit the window, reenter the window, click in the location bar, it starts accepting the events. - sometimes the input gets locked similarly by other sequences of events than starting a window; I did not identify which sequence of events that makes it happen (sorry). Some data --------- - ALL my mozilla custom settings, from a new install (very few): - theme = modern - start page: "Blank Page" for both navigator startup and new window - proportional font: Sans Serif That's it, nothing else. - deleting my .mozilla and starting again doesn't help, problem persists. - distro: Gentoo linux (no version, continuously updated). - my USE flag for Gentoo:: USE="X gtk gnome alsa acpi apache2 apm avi cdr cjk crypt cups curl -doc emacs encode aRts esd gb gd gdbm gif gphoto2 gpm gtk2 gtkhtml guile imap imlib jack jpeg kde ladcca lcms leim libg++ libgda libwww mad maildir mbox mcal mikmod memlimit mmx motif mozilla mpeg mpi mule mysql ncurses nls oggvorbis opengl oss pam ppds pdflib perl plotutils png python qt quicktime readline ruby samba sasl sdl slang slp snmp spell sse ssl tcltk tetex tiff truetype usb wmf wxwindows xml xml2 xmms xv zlib -ldap" - window manager: ctwm; I also tried with sawfish and the problem is similar; - kernel 2.4.22 from kernel.org (gentoo: vanilla-sources); - window manager: I run ctwm; I also tested using sawfish, similar problems occur; If you need any more information, let me know. Martin Blais <email@example.com>
I've been experiencing the same problem for at least over a year now (first with Mozilla, now with Mozilla Firebird 0.7). It is also close to 100% reproducible: 1) Open a Mozilla window on a (fluxbox) workspace without any other windows 2) Put the cursor in the address bar 3) Move the mouse out of the address bar and over the page area 4) Switch to another workspace 5) Switch back to the workspace with Mozilla 6) Click on the address bar 7) Try to start typing <-- doesn't work Unlocking it works as described earlier: 1) Click somewhere on the page (to get the cursor out of the address bar) 2) Switch to another workspace 3) Switch back to the workspace with Mozilla 4) Click on the address bar 5) Start typing <-- works What I noticed is that the problem only happens if --enable-default-toolkit=gtk2 is provided to configure.
We're in good shape on this. I haven't seen any real issues in a long time. I guess we can keep th meta bug open for when new issues crop up.
Since the great majority of bugs are fixed I want to mark this meta bug fixed now.
Status: NEW → RESOLVED
Closed: 19 years ago → 16 years ago
Resolution: --- → FIXED
"Since the great majority of bugs are fixed I want to mark this meta bug fixed now." Huh?! This is the single bug that makes mozilla pretty much useless for me and anyone else it affects. Losing keyboard randomly requiring a dance with iconifying and de-iconifying windows to get it back is not normal behaviour. It has never been fixed and it's been in mozilla for years. I've been complaining about this for years, and really find it amazing that such a debilitating bug that affects so many people could possibly remain in any software for so long. But remain it does. closing bugs just because, "you know, we've fixed lots of bugs so we probably fixed this one sometime", is pretty bogus.
(In reply to comment #35) > Huh?! I closed this meta bug, not the 3 individual bugs with specific issues. Meta bugs are not places where things actually get fixed and they don't deal with specific testcases. Which of those 3 bugs is still an issue for you? Otherwise please point me to the comment that describes your problem and we get open a bug specific to that problem. Believe me, as the accessibility owner I don't want keydead bugs in Mozilla, and have fixed some pretty difficult ones myself.
Ah, I understand your original sentence now. I think the reason you see so many closed bugs is becuase most of the bugs attached to this meta bug appear closed because they're all duplicates of each other. There are probably only one or two actual long-standing bugs here that people keep finding ways to trigger. For the record, of the three remaining bugs, bug 78928 seems to most closely match my problem. Mostly in that it talks about twm and the no-window-manager cases. I suspect the other two are in fact the same bug, but it's hard to tell. I've tried with titlebars and turning off notitlebarfocus (though I normally run without titlebars) and can't eliminate the problem.
This bug is so old that the engineers and testers who might care all have different assumptions about it right now, which is why it's important to "shake things up" sometimes and mark a bug fixed so that people can come out and disagree, and fresh information is again logged :) If there's you can add to bug 70812 to help engineers via more info I suggest you do it in that bug.
I see comment #38 beeing totally valid. There were afaik some huge focusing issues when I originally filed that bug which don't apply to the post 1.0 Mozilla era.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.