This is Bugzilla: the Mozilla bug system. For more information about what Bugzilla is and what it can do, see mozilla.org's bug pages.

Bugzilla Bug 82534

Cannot type in URL bar or text boxes - no caret. (Keyboard locks up / no input)

     Query page      Enter new bug

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9+) Gecko/20010523
BuildID:    2001052320

Through normal use of Mozilla, it will eventually get to a point where I cannot
type in the URL bar.   I click on it, but the caret never appears there.  
Typing does nothing.   The only way to fix it is to close the Mozilla window and
open a new one.

Reproducible: Sometimes
Steps to Reproduce:
1.Use Mozilla for a bit
2.Type something in the URL bar
3.

Actual Results:  Nothing can be typed in

Expected Results:  Typing appears

Can you reproduce this problem?
If so, can you try typing in a form element; does that work?
Can you click on a link; does that work?

I think this is a duplicate bug...

This also occurs for text boxes within pages.   Switching to another Mozilla
window and back again usually fixes it.

I know this is still happening in some situations. Problem is, I don't have good
test cases. If you can reproduce this easily, tell me. If it happens a lot while
doing something in particular, like opening mail messages in a new window, tell
me. I need as much info as possible on this.

I've encountered this exact same problem on Linux using NS4. I don't know if
it's related or not, but it may not be Mozilla specific.

The same for me on Linux mozilla. I'm occassionally unable to write any text or
use any links (also maybe for menus which I can pull down but not activate). The
cure I use is to switch to another Mozilla window and move the cursor over a
link. Then I switch back to the first window and everything is working again.

I have the same behavior with W2K. After a while I can select address in YRL bar
and get the caret, but when I try to type over the address or delete it with
delete it does nothing. open web location works thou.

I can't reproduce it easily, url bar just stops after a while. I noticed the
problem a couple weeks ago I believe. it happens with build 2001052904 that I
use at the moment.

Panu

As far as I can tell, it happens shortly after you click one of the links in 
your personal toolbar, that uses cookies to log in.. Like Slashdot or something 
similar.  It did start happening a couple weeks ago though.  I'll experiment 
today and find which build it was that started this.

In the 2001051420 build it doesn't do this, however in the builds starting on 
the 15th it does.  

Just for fun, I let today's build sit there doing nothing for awhile.  I just
opened it and let it sit.  To browse with at a later date.  I came back to it
maybe 10 minutes later and the URL Bar didn't work.  So you don't have to do
anything for it not to work.  Just let it sit for however long it takes.  This
really really sucks.

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

Is it a dupe of bug 30841?

I don't think so...  

This bug doesn't involve right-clicking or context menus.
Also, switching to another window and back again fixes this problem, but not bug
30841

Panu Artimo: what you are seeing might be bug 30841 as you can see the caret. In
this bug the caret doesn't appear.
Patrick Keller and wdormann: could you run mozilla with the -console option? See
if there might be anything that appears in the console when this happen. Also
check the javascript console [Task->Tools->JavaScript Console].

Nothing in the console or Javascript debug window.  *BUT* I did find a 100%
reproducible way of showing this bug.  (at least on my system).   This should
work on any Win98+ or Win2k+ system.

1)  Launch Mozilla
2)  Hit Ctrl-N to open a new mozilla window.

  ** at this point there are 2 mozilla taskbar items: (1) and (2)

3)  Press taskbar button (2) three times. (not too quickly)  This will Minimize,
Maximize, and then Minimize the second mozilla window.

You are now presented with the first Mozilla window.  You can not type in the
URL box at all.   (at least for me).   You can click there, but no caret ever
appears, and you can't type.

this is an editor bug, possibly a focus issue

wdormann: confirm on build 2001061304 win32 talkback installer sea trunk win98

focus-->saari

with build 2001061404 win32 talkback installer sea trunk win98
I can no longer reproduce it. Note that I've done a "clean" reinstall and
removed my old profile and started a new one.

Yeah, this is a general problem when the browser goes "event dead" or "key
dead". There are several bugs, many of which have been patched and there is
still one patch coming in soon that should make this better. If you can find
what build this frist appeared in, or a nice reproduceable test case, that would
be great. Otherwise, weigh in whenever you see it.

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

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

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

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

One case where I frequently see this bug is when I do a VNC session to another
pc using Mozilla, and then disconnect.   I can't type in the URLBar until I
switch to another window and then back again.

WD, can you give me specifics on how to reproduce that? URLs, steps, platform,
etc. Thanks.

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

     I don't understand why these are dupes! 92531 is about being ABLE to 
type the address in and mozilla not loading the page. 82534 is about NOT 
being able to type the address in at all.

The expected results for 82534 are:
Typing (should) appear(s)

The expected results for 92531 are:
The browser should load all the web address I ENTER (emphasis mine) 
into the adress bar at the top of the page without failing or freezing.

You should "un-dupe" 92531, as it is not about typing but about loading.

->0.9.5 unless I get a way to repro this

I tried the following and it WORKSFORME:


1)  Launch Mozilla
2)  Hit Ctrl-N to open a new mozilla window.

  ** at this point there are 2 mozilla taskbar items: (1) and (2)

3)  Press taskbar button (2) three times. (not too quickly)  This will Minimize,
Maximize, and then Minimize the second mozilla window.

You are now presented with the first Mozilla window.  You can not type in the
URL box at all.   (at least for me).   You can click there, but no caret ever
appears, and you can't type.

Yes, this bug has nearly disappared.   The steps which I originally posted to 
reproduce now WFM.     I have intermittently came across this problem when 
using VNC, though.  (After disconnecting from a VNC session, I can't get the 
caret to appear in the URLbar).    I'll posts steps to reproduce if I can come 
up with something that shows the problem consistently.

I agree with David T. that 82534 and 92531 are not dups. I believe they are
seperate bugs. From the summary "Cannot type in URL bar or text boxes - no
caret" this is not what I reported when I posted bug 92531. With 92531 when a a
url link is clicked on by the mouse and it fails, the broser hangs/freezes. Bug
92531 was not a bug about typing into the url bar, It was about cliking a url
link and the browser hanging and freezing. Has anyone besides myself test bug
92531 with Mac OS 8.6 since the part about hanging and freezing may only be
specific to this OS version. I believe these two bugs are definitely not dups.
Can anyone help me verify this? Thanks.

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

Steps to reproduce:    (I'm using 2001082203)
1) Connect to a machine running VNC with Mozilla   (http://<server>:5800)
2) Log in
3) Select File -> New Navigator Window

The new Mozilla window that is created will not accept any typing in the URLbar

Yep, I've just by chance experienced what WD describes with Linux 2001082208.

I have definite proof that this is something to do with focus. I noticed one
time when this happened, I had a terminal window underneath mozilla, and instead
of the focus being on mozilla, it was in the window underneath. I don't know
what triggered it, but it may not be a problem with mozilla per se, it may be
somehow a result of X misbehaving.

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

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

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

A 100% reproducible testcase for Win32 is described in bug 111250. But no output
at JS console :(

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

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

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

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

Confirmed independent of quicklaunch (reproduceable either way).

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

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

Interesting effect with 0.9.6 on Linux (gcc2.95.2 based,
but using installer build i686): When the textboxes 
are blocked, typing an 'f' starts the bookmark manager.
Also, when luckily getting an unblocked  first navigator,
starting the bookmark manager and closing again initiates
the blocking effect.
Seems that somehow that guy grabs the wrong focus.

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

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

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

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

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

This may or may not be useful information Using the latest nightlie from 0.96 
to current nightly I do not encounter this bug on Mac OS 8.6. I tested 0.96 and
a nightly from December 5 with Mac OS 8.5 and could not type anywhere in
Mozilla. My computer functioned as if I had disconected the keyboard and only
had a mouse plugged in. (OS 8.5 shipped with my computer). I  know OS 8.5 is
unsupported. I am hoping this extra information might assist someone with Mac OS
knowledge to narrow down this bugs cause. (BTW we don't need to support Mac OS
8.5 since the update to 8.6 from 8.5 is a free download on the Apple site).

The problem described in comment 53 is unrelated to this bug.  It is specific to
MacOS8.5.  This bug is a problem that has been around on all platforms much
longer than the typing problem.  See bug 110828 for Mac-specific problem on OS8.5.

Any relation to <A HREF="http://bugzilla.mozilla.org/show_bug.cgi?id=108787">
bug 108787</A> (has a patch now) ? Maybe there's a hint for what's 
going on here ?

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

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

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

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

A 'sticky' pulldown menu will kill the ability to type anything in any part of
Mozilla.  I've been having this problem for a while now, on Mac 9.1, since 0.9.4
at least, but wanted to be very sure before I added to this discussion:

Steps to replicate:

1. Open a browser window.
2. Use any pull down menu associated with the window itself, like the Back button.
3. Eventually, the window goes event dead.
4. If you clear the sticking pull down, you get the caret back.

This is especially a problem with folders in the Personal Toolbar, but the Back
and Forward buttons are just as effective.

 

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

Just an observation. I seem to recall a similar problem with an earlier version
of Netscape (maybe 18 months ago), which was also "resolved" by switching to
another window, then back.

As observed above, typing an "f" does indeed start the bookmark manager.

In my case, the window is "key dead", but not "mouse dead" - I can still cut &
paste into the URL or text window, but no keyboard stroke is recognized.

It seems to "go dead" when the screen times out or when the screen saver starts
up. X Window/Desktop problem?

"In my case, the window is "key dead", but not "mouse dead" - I can still cut &
paste into the URL or text window, but no keyboard stroke is recognized."

I'd agree that this is exactly the behaviour I'm seeing as well.  However, I'm
having it occur in both the Windows and Linux builds of 0.9.7.

Once this occurs, the keyboard is effectively dead for Mozilla use.  

On comment #62:
This is definitely not screensaver dependent. I see this
problem without any timeout interfering.
By the way, the 0.9.7 release also does not show
the Bookmarks and the Home label in the first window, 
only the icon, a problem which also does disappear when
a second window is started. Seems that some parts of the
initialization process of the initial window are broken.

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

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

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

ok I can reproduce this bug perfectly on milstone 0.9.7  on a debian linux box
running kernel 2.4.17 

Steps
1) start browser 
2) from file menu pick open web site
2) enter any web site ie www.google.com 
3) hit ok
4) from then on I can't type into any text form or the url bar 

The stated testcase performs correctly on my 0.9.7 on Debian.  I have no problem
and I can type in all text boxes.  Perhaps the problem lies with focus and the
window manager.  For example, the "Open Web Location" dialog has an
auto-complete widget, but with my focus settings, the main autocomplete widget
on the main URL bar steals the focus from the dialog while I am typing. 
Obviously there is some focus issue in there somewhere.

Testcase procedure in comment 68 causes the problem to occur in 0.9.7 on my
Slackware box (kernel 2.2.19, Blackbox WM), however, it did not reproduce the
problem in 0.9.7 on Windows 98SE.  On the other hand, I have seen this problem
occur in Windows, so it's not like it's immune.... 

it does seem to be a focus issue because after it happens I can always get the
keyboard functionality back by switching focus to another program and then
switching back. I am using fluxbox wm which is a derivitive of blackbox.

To comment #71:

This does not function on Linux with fvwm2. 
Testcase: Open Navigator, open 'manage Bookmarks',
          close it ==> focus in Navigator is lost.
  There's no way to get the focus back by switching
  to another program. Instead, all input seems to
  to be going to the bookmarks manager (type, e.g., 'f').

Too much traffic...

This is probably related to bug 107405.  Many people are noticing symptoms in
that bug that are the same as the symptoms of this bug.  There is a definitive
test case on 107405 that seems to cause the problem nearly 100% of the time.

(1) Starting Mail/News first, with quick launch enabled.
(2) Minimizing that (mail/news) window to the taskbar on Win2k and WinME
(3) Right-clicking the mozilla icon from the tray, and selecting "Navigator"
    (a) A browser window opens, bringing me to my home page
(4) Any attempts to enter text into any field on the page (or location bar)
fail, with NO blinking cursor.

More notes:
(1) Pressing "a" key will refresh page, and "n" key will open a new tab, as
pointed out by Gavin.  However, I do NOT have the "new_window=new_tab" pref set.

(2) Restoring the Mail/news window (un-minimizing it from the taskbar) will
restore the ability to type into the browser window

(3) It does not appear to be anything related to the page loaded in the browser
(I tried many different types of 'home' pages)

(4) Mouse function is not affected, nor is keyboard function in other running
programs on my computer.

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

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

I would like to see this marked as a BLOCKER:
When I can't type into the first window, I cannot
test correctness of any functionality in the first
window, checking for correct initialization (which
is definitely not correct for this case). This guy
REALLY SUCKS, so it should be fixed immediately !
nsbeta1 is far too late.

can someone who can repro this try w/ a trunk build now that 122462 has landed
and report back?

Bug is still present with 2002013003 trunk build pulled at 5:40 PM EST

I have a further way to reproduce this bug on my system.

1) Open new mozilla window
2) while loading home page (ie can't be about:blank), click folder (in my case
"links") in personal toolbar and move down. menu will disappear, and links menu
will move right (I have to check for a separate bug on this). There is a dead
image of the links folder to the right of the new links folder.
3) you can no longer type anywhere in the url bar, page forms, etc.

If there is any further info. I can provide, let me know. I have build
2001122106 on win32 with talkback.

This only happens when quick launch is enabled... WTF is quick launch doing to
break this? How is a window minimized under quick launch? I'm thinking this is
just a dup of an issue when windows are minimized...

It's not related to QL.  I can reproduce this just by starting moz from my
desktop, minimizing that nav window, double clicking the desktop icon again, and
trying to interact with that new window.

I'm glad we finally found a reproducible, common case of "can't type in urlbar"
though, since that's such a common complaint.

Grrrrr. Okay. I'm about to close this bug because we're all talking about
different things and it is overloaded.

The steps in Comment #74 only reproduce when QL is enabled. 
Blake, please file a different bug for your approach since they have divergance
on the QL necessity.

That said, they probably are the same bug in reality, depending on how QL is
implemented (if it just has a minimized window or equivalent).

The steps to reproduce in comment #33 still hold true.  (I believe step 2 isn't
even necessary).    Quicklaunch is in no way required to reproduce.

I'll add that following the procedure in Comment 68, keyboard functionality can
be returned by giving focus to another, non-Mozilla window, and then returning
focus (and keyboard control) to Mozilla.  Works everytime for me.

Looks like this guy silently died ! 
WFM Release 0.9.8 Linux.

marking WFM based on latest comments. If this is still not working
for anyone, then REOPEN with a reproducible test case.

verified.

Steps in comment #33 still show this bug.
Win2k 0.9.8 release
(step 2 is not necessary)

Re-opening

With 0.9.8 on Win2k the steps from comment #74 still reproduce this bug this for
me. Sorry, no silent death here :-(

Addition to comment #91:

Just when working with 0.9.8 every once in a while the problem occurs as well
when opening a new browser window. Not reproducable though but the same behaviour.

It looks like creating a new window after viewing any page with java will do it
every time. (at least on my Win98 box)
Repro:

1) Go to http://www.javasoft.com
2) File -> New Window
3) Try to type in a new URL

Seems to be a windows only or at least non-Linux
problem (#92 ?) now. All procedures mentioned here
(except the VNC case, which I cannot test) work
for me under Linux (gcc 2.95.3 compiled 2.4.16).
Maybe it's a different guy lurking behind those
cases ?

This could be a clue - although I cannot replicate it by the method I gave in
comment #80 after 0.9.8, when it did occur for me I was opening a page with a
small Java applet in it.
This is despite the fact that I have not been able to get the Java plug-in to
work at all, even though I have 2 JDK's and the JRE installed... (which reminds
me to go and check for a bug for that :)

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

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

nsbeta1+ per ADT triage team

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

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

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

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

I noticed a new 100% way to reproduce this bug (at least for the session I'm
using write now, God knows if that holds true tomorrow):
In the 3 pane mail window (message header area), right click on a message sender
field (i.e. "From"). In the context menu, select "Add to Address Book". In the
"New Card" dialog that appears, I am not able to write on any entry field. No
caret. Now, if I open  a new window from browser, caret appears and keyboard
entry is possible in the previously malfunctioning New Card dialog. That
perfectly resembles of this bug. No need to file another one.

Forgot to post the build ID (2002021303 and 2002021403) and the OS I used (Win98
and Win2K). As for my terrible spelling errors, what can I say ...

I noticed someone just posted a way to reproduce this while i was typing out my
way.  I think mine is simpler and may provide insight into the major problem

100% reproducable for me. (win32)

step 1:  start original mozilla window.
step 2:  minimize window
step 3:  open a second mozilla window.

Wala!  URL bar not accepting most keyboard input.  I suspect that this has to do
with Mozilla still considering itself minimized (out of focus) when a new window
is opened.

This seems to hapen whenever all mozilla windows are minimized and a new one is
brought up.  (in my test case, via quicklaunch --mozilla quick launch, not MS
shortcuts, though those reproduce too)

Related:  Just grabbed a build (2002021413) and the problem as worsened.  If i
start up an original mozilla window and try to minimize it, it pops right back
up.  Seem like it may have been an attempted fix.

#103 and #105 WFM Linux 0.9.8.
Taking into account all recent duplicates, platform/OS
seems to be limited to PC/WindowsXX now. Any counter-examples ?

Re on comment #105: Gabriel, identical testcase was originally posted in comment
#82. But I agree it's 100% reproducible, too. I posted mine because I wanted to
pint out that this damn bug, besides browser, also affects other parts of the
application.

oh, I know, account wizard is plagued by this problem too.. it appears that
within bugzilla there are several bugs linked to the first browser window or
first mail/window or first account wizard window.. there is a possible
chrome/XUL/XBL/focus problem in Mozilla.. I've seen it with seperate components
not working correctly the first time you use it..

-dennis

  I can confirm that the method posted by gdf @ gsource.org reproduces the bug
100%; W2K SP2. But apart from the original description I must add that rising
one of the minimized Mozilla windows makes the "ill" window work corectly.

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

Method of reporoduction detailed in
http://bugzilla.mozilla.org/show_bug.cgi?id=82534#c105 

Is reproducable in win32-talkback build 0.9.5  but *not* reproducable in 0.9.4
and before.  

I think this bug may have morphed over the years do to other bug 'fixes'.

It may be just a coincidence, but i can make 0.9.4 reproduce the exact same
behavior as 0.9.5+ if i remove US.jar from the chrome directory.   

the url field goes mad usually after loading non-html pages, for example
macromedia flash (swf) files, ... (Windows 2000)

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

Created an attachment (id=73116)
something to fix more cases on win32

With this patch, I can no longer reproduce the case for which I originally filed
this bug.  ( comment #93 )
Steps in comment #105 do not show the bug either.  (Though I cannot say I have
tried those steps w/o the patch)

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

I just opened bug no.130480 before I was sent to this.  In my write-up, I gave
specific steps to reproduce:  Type an non-existing or down website into the
address bar.  After recieving the no domain found dialog, address bar and all
text fields do not accept text.

118: This works in Linux i686 0.9.8

I also have not seen a recurrence since switching to Linux 0.9.8 2002020511

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

I have had this bug on every build since .9.5 and I am now running .9.9. I have
quick launch enabled and its running on a winXP Pro install. Full Install of
Mozilla.

I also have this problem with a fresh install of version .9.9 (no previous
version of mozilla 5 was installed, but Netscape 4.5 is installed on same
machine). on a WinNT workstation, Service Pack 5. With this installation I have
everything installed except for the Mail and Chat program.

Closing the affected window and opening a new one does seem to be the
work-around for this from a useablity standpoint.

(this has to be the most irritating bug ever)

I have this bug too. My workaround is - Ctrl+Shit+L followed by ESC - it makes
URL address bar unfrozen again. This bug is too old in my opionion and should be
fixed soon.

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

Test case that always works for me. (and it's fun!!!)
1. Open a new Mozilla window with or without Quicklaund enabled.
2. Go to http://www.coolmath4kids.com/games/radialpong/  and play with the fun
little java applet there for about 10 seconds (or more if you're having fun)
3. Go to File -> New Navigator Window
4. COngrats! Your URL bar in the new window no longer works.

Confirming reproducability of Testcase on 2002032903 on W2K.

This happened for me with 0.9.6, 0.9.7, 0.9.8, and 0.9.9.

Running Windows NT 4.0 Workstation.

Sometimes happens immediately after starting - I have to close mozilla
and reopen to fix.

For me, when this happenes, the cursor changes to I-Bar when hovering near the
text box, but clicking in text field doesn't place caret,
so I can't enter text - but if there is text I can select words by clicking on
them, and even delete the selected text with keyboard.

Confirm comment #125 with URL http://www.coolmath4kids.com/games/radialpong/; it
is a valid way to reproduce the bug on W2K SP2 with 2002031104.

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

An other way to lock the URL field:
1. press the 'print preview' button
2. on the preview window click close
3. the url-field is locked

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:0.9.9) Gecko/20020311

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

saari: your patch (attachment 73116) seems to fix some Linux issues as well as
Win32 ones.  is this destined for checkin anytime soon?

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

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

I get this problem sometimes when trying to type in the To: field in Mail 
messagse.  If I click "Compose" and then try to type in the To: field, nothing 
happens.  If I click the mouse in the To: field, I still can't get the cursor 
to show up there.  If I click in the message body area, however, I can type 
stuff.  If I then try to go back to the To: field, I still can't type stuff.

Addition to Comment #130:
Text boxes, input fields etc become locked for keyboard access, too.
The focus is no longer movable by keyboard.

Some quick tests on Linux have found this to be a window manager issue (at least
in my case).  Running Slackware 8.0 with the Fluxbox WM (Blackbox derivative). 
Changing WM has solved this problem for me on Linux.  

However, the testcase in Comment #125 reproduced the problem in Win98.

This is 0.9.9 in both cases.

Maybe this is Win32 only at this point....?

I can reproduce this 100% with the 2002-04-10-11-1.0.0 build on a rh 7.1
Linux/x86 kernel 2.4.16 KDE 2.1.1/XFree86 4.1.0 system:

1.  Start mozilla via (in my case) ~/mozilla/2002041011-1.0.0/mozilla -mail
2.  Press ctrl-M for new message.
3.  Focus works fine; caret is blinking in the To: box.
4.  Close the new message window.
5.  Press ctrl-M for new message again.
6.  No focus in To: or Subject: boxes, clicking does not help.

Notes:  tabbing to the body pane works, in that the body pane accepts keyboard
input.  Reverse-tabbing back to the To: or Subject: boxes returns partial
functionality (characters show up, but no caret).

Clicking or alt-tabbing to another window then back restores normal operation
(To: and Subject: boxes accept focus via mouse, and show blinking caret).  The
"Save, Don't Save, Cancel" dialog is sufficient to make things work again.

Brian,

That's bug 130581. There's two workarounds mentioned in that bug too.

Per Gabriel's comment #105:

I have this very same problem under Win32 -- it happens on my Win95, Win98SE,
and WinNT4.0 boxes. Interestingly enough, hitting Ctrl+N to open a new window
always results in a working location bar. But double-clicking the mozilla icon
on my desktop, while Mozilla is already open, nearly always results in a
*non-working* location bar. This has been the case for a LONG time.

Under Linux (debian "woody" current as of today, april 2002, linux 2.4.17, glibc
2.2, x 4.1.0, kde 2.2.2) this problem is non-existent. At least for me. ;-)

Adding myself to the cc list.

The bug described here
http://bugzilla.mozilla.org/show_bug.cgi?id=130482

is very similar to this one and it not yet solved with the latest
nightly build
Mozilla 0.9.9+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020414

Just FYI

happens for me too on winxp but not on linux debian... both times tested with
latest build... why don't we add mozilla1.0+ keyword??! this bug is very highly
visible on windows... and it's really annoying since you always have to restart
the whole browser :(

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

Adding myself as a cc since someone reported seeing this on OpenVMS today.

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

More data:
Happens to me with QL on, goes away after turning it off. Build 2002-04-16-17.
Win 2k.

I'm seeing this with rc1 on Linux.  This should be fixed before mozilla goes gold.

I still have not seen this on Linux again 'til 0.9.8.
Did you start on an absolutely clean personal folder .mozilla ?
Did you install into a clean mozilla directory ?
I use Fvwm 2.4.0, Linux 2.4.18, all gcc2.95.3 compiled, but
ordinary x86 Linux 1.0.0-rc1 build.

it seems to work with the latest incarnation of the mozilla

Mozilla 1.0 Release Candidate 1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417

RH6.2 kernel 2.2.14-5.0


Yes, this bug is gone...  it is solved 99.99%

A small bug still exist...  

So, here is the desription:
Yes, I can click on "File" and select "Send Link.."
yes, I can send the e-mail

yes, I can send the e-mail for the second time (which was 
the main topic of the bug 130482)

Yes , I can click on To:  and enter the address
Yes, I can click on body and write the message
yes, I can click again on "To:" and enter another address
yes, I can click again on body and continue writing the message
(I can repeat this sequence as many time as I want)

but

I CAN NOT click on URL (which is written in the body)
if I come from "To" field 

and another but

I CAN click at the end of the URL line and move the cursor
back into the URL...  After this action I can click
with a mouse anywhere in the URL

I think this should be fixed as well....
Many times I want to edit the URL , before I send it.

REMAINDER:
URL is a part of the body, because we started the process
with "File --> Send Link..." 

#149 WFM as in #148

I can still reproduce this problem using Mozilla 1.0 RC1 on Windows 2000 SP2
using the technique outlined in <A
href="http://bugzilla.mozilla.org/show_bug.cgi?id=82534#c105">comment 105</a>.

Also reproduced as above on Windows XP (moziilaRC1)

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

I can reproduce this via the technique in comment #105 on Windows ME too.
(mozilla 1.0 RC1)

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

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

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

I have this Problem too, with Mozilla RC1, Using Windows XP, this MUST be 
fixed fast, we can't release Mozilla 1.0 with this bug, seriously!

what about mozilla1.0+ flag?