Dimitrios Reporter
	Description • 24 years ago

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.

	Jesse Ruderman
	Comment 1 • 24 years ago

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.

	Alec Flett
	Comment 2 • 24 years ago

thanks for creating this! I'm marking this moz 1.0, but that doesn't mean the
dependant bugs won't be fixed :)

	sairuh (rarely reading bugmail)
	Comment 3 • 24 years ago

adding more dependencies:

bug 71493: content area doesn't keep focus following links
bug 58250: keys don't always scroll page

	Stephan Niemz
	Comment 4 • 24 years ago

Adding that mostfreq bug 54936 "Dismissing a dialog confuses the focus"

	Peter Trudelle
	Comment 5 • 24 years ago

Has anyone ever seen this in an embedded Gecko (WinEmbed, MFCEmbed, gtkEmbed,
...)?

	Jesse Ruderman
	Comment 6 • 24 years ago

Adding bug 76621, sidebar elements should not grab focus from other parts of 
window.

	xolaware.llc
	Comment 7 • 23 years ago

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.

	Aaron Leventhal Assignee
	Comment 8 • 23 years ago

Focus issue -> bryner

	Ken Harris
	Comment 9 • 23 years ago

Is bug #76393 one of these?

	saari (gone)
	Comment 10 • 23 years ago

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?

	Aaron Leventhal Assignee
	Comment 11 • 23 years ago

Chris, I'm fine with closing this - although I think 67977 is still worth fixing
when someone comes up with a good solution.

	Brian Ryner (not reading)
	Comment 12 • 23 years ago

ok, closing.

	Skewer
	Comment 13 • 23 years ago

Reopening due to the blocker bug 101239.

	Brian Ryner (not reading)
	Comment 14 • 23 years ago

Er, I don't think we really need to reopen this bug every time a bug pops up
that hangs the app.

	Jesse Ruderman
	Comment 15 • 23 years ago

-> nobody

	Asa Dotzler [:asa]
	Comment 16 • 23 years ago

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)

	Dan Tobias
	Comment 17 • 23 years ago

Bug 104561 is another of this sort...

	Andrew Hagen
	Comment 18 • 23 years ago

Is bug 90337 this as well?

	Holger Faustmann
	Comment 19 • 22 years ago

Mozilla stops accepting keyboard input when i switch in mac os 9, from a open
.htaccess-dialog to the finder. 

	Jason Kennerly
	Comment 20 • 22 years ago

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.

	Tal Cohen
	Comment 21 • 22 years ago

(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).

	Jeffrey Friedl
	Comment 22 • 22 years ago

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.

	Fredrick Knieper
	Comment 23 • 22 years ago

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.

	gsstark
	Comment 24 • 21 years ago

surely having the browser repeatedly stop accepting keyboard input is worth 
assigning to someone? It's nearly completely unusable in its current state. 

	Vedran Miletic
	Comment 25 • 21 years ago

retargeting

	mozbugzilla
	Comment 26 • 21 years ago

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.

	Ashley Bischoff (blog at handcoding.com)
	Comment 27 • 21 years ago

-> Component's default owner

("Reassign[ed] bug to owner and QA contact of selected component")

	Henrik Sankala
	Comment 28 • 21 years ago

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.

	David Babcock
	Comment 29 • 21 years ago

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

	David Babcock
	Comment 30 • 21 years ago

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.

	Martin Blais
	Comment 31 • 21 years ago

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 <blais@furius.ca>

	Maurice van der Pot
	Comment 32 • 21 years ago

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.

	Aaron Leventhal Assignee
	Comment 33 • 20 years ago

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.

	Aaron Leventhal Assignee
	Comment 34 • 20 years ago

Since the great majority of bugs are fixed I want to mark this meta bug fixed now. 

	gsstark
	Comment 35 • 20 years ago

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

	Aaron Leventhal Assignee
	Comment 36 • 20 years ago

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

	gsstark
	Comment 37 • 20 years ago

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. 
 

	Aaron Leventhal Assignee
	Comment 38 • 20 years ago

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.

	Dimitrios Reporter
	Comment 39 • 20 years ago

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.