Closed Bug 82534 Opened 24 years ago Closed 22 years ago

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

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: wd, Assigned: saari)

References

Details

(Keywords: access, relnote, Whiteboard: *Read* comments #287 and #330 first! [ADT1 RTM] [ETA 06/26] [verified on win32 trunk])

Attachments

(2 files, 1 obsolete file)

fixed spacing in the patch
5.82 KB, patch
bryner
: review+
jag+mozilla
: superreview+
jud
: approval+
Details | Diff | Splinter Review
sourece code from working and non-working pages
23.55 KB, text/plain
Details
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.
Summary: Cannot type in URL bar - no caret → Cannot type in URL bar or text boxes - no caret
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.
OS: Windows ME → All
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.
Keywords: access
*** 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
Assignee: alecf → beppe
Component: URL Bar → Editor
QA Contact: claudius → sujay
wdormann: confirm on build 2001061304 win32 talkback installer sea trunk win98
focus-->saari
Assignee: beppe → 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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.3
*** 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. ***
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Hardware: PC → All
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
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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. ***
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** 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. ***
Blocks: keydead
*** 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. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.8
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. ***
Summary: Cannot type in URL bar or text boxes - no caret → Cannot type in URL bar or text boxes - no caret. (Keyboard locks up / no input)
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.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
can someone who can repro this try w/ a trunk build now that 122462 has landed and report back?
Target Milestone: mozilla0.9.9 → mozilla1.0
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
Steps in comment #33 still show this bug. Win2k 0.9.8 release (step 2 is not necessary) Re-opening
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
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
Keywords: nsbeta1 → nsbeta1+
*** 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. ***
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+****+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 [details] [diff] [review]) 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?
I am able to reproduce this as well under Windows 2000. (same method as comment 105) Launch Mozilla Minimize it Launch another copy <focus problem> Click on something else like desktop Click on open Mozilla (second copy) <problem is gone>
By opening a second Mozilla browser, under the Modern theme, I am able reproduce this.
Such an easy to reproduce bug. Open Mozilla using Modern Theme. Open Mozilla window from the desktop icon or quick launch icon. Try to get the forms to work on that second one. Forget it.
*** Bug 142583 has been marked as a duplicate of this bug. ***
*** Bug 143263 has been marked as a duplicate of this bug. ***
Blocks: Beonex
*** Bug 143121 has been marked as a duplicate of this bug. ***
I don't know if this helps, but the error occured while I was at www.candystand.com playing billiards. It hasn't happened anywhere else yet. I was playing the single player contest and couldn't click on the address bar or fill out any forms afterwards when directed here to fill out a bug form.
Method from comment #105 is valid for Rc2 on W2K. What's more annoying is a "new" behavior: start original Mozilla (Modern Theme), which is maximized; minimize it and from the desktop link (I must stress this: use the desktop link!) start a new Mozilla window; guess what? The newly launched window does not accept input but it also "forgot" that it should be maximized! Mozilla started from the taskbar works very well. My favorite method to reproduce the bug on Rc2 W2k (2002051006): 1. No Mozilla running but quick launch enabled 2. Start Mozilla mail from task bar 3. Make an advanced search via the search button in mail a search that should produce no results. 3.1 press Advanced in the search tab 3.2 type qweqre4234532fgs or something appropriate in the input box after "subject contains" 3.3 press "search" 3.4 press "clear" 3.5 press search again 3.5 close the search window by clicking on the X from the upper right of the window 3.6 minimize MM using the window button 4. Start new Mozilla from the desktop link watch that the URL bar works (cursor blinks); close the window 5. Open new Mozilla window using the same link from the desktop. The URL bar is now dead in terms of input but it accepts browsing the history click the drop down! It looks like it is set "read only"... Again: do use the desktop shortcuts because those from the W2k's bar do not display the problem!! Another important thing: flawed windows opened with the second method do not revert to normal behavior no matter how many of them you open; you have to close Mozilla mail.
Happens sometimes on WinXP Eng. Build 2002051006.
This bug is back in 1.0rc2 on Win2000. I never saw it in 1.0rc1.
*** Bug 144231 has been marked as a duplicate of this bug. ***
I have experienced this same issue on Windows 2000 Machines. It seems to happen only when more than one mozilla window is open, or when mozilla has been closed but it still resident in memory (quick start). I have been able to "fix" the problem by completely closing Mozilla, including the quick start icon, and then re-opening. For some reason it seems that in multiple browser window situations perhaps mozilla is locking input into one of the open URL bar's. To reproduce the problem, I have followed the following steps: 1. Open Mozilla, visit 2 to three websites. 2. Minimize window #1. 3. Restore Window #1 and spawn another browser. 4. 90% of the time this re-creates the problem. I hope some of this can help! Blane Boynton (b.boynton@acrtucson.com) IT Admin ACR, Inc.
I wonder if this one has any relation to bug 143222, which is 100% reproducable for me on different platforms. Somebody please check it out?
It happens to me on NT4 when Mozilla has been running for a while. If I double-click the Mozilla icon to open a new window, text entry doesn't work in the URL bar or in forms. If I close that window, then open another one, it works.
Can we all move this discussion to usenet, there is nothing more too see here, we all know its still happening. Please only post if you have a patch to post, or once its been marked fixed, to reopen if its not. Otherwise the many many me-to post are waisting the developers time.
########## Summary Even if I think <a HREF="#c174">#174</a> is quite right, let me sum up what I found reading nearly all comments - puh...: 1. I think <a HREF="#c105">#105</a> is the best way to reproduce this bug <i>(Open one or more mozilla windows, minimize all(!), and open another one - it's locked)</i> and, as stated there, simple and may gives the best insight into the real problem! 2. The fastest workaround (for keyboard users only ;-) when using browser is from <a HREF="#c123">#123</a> <i>(using Ctrl+Shift+L followed by ESC)</i>. Generally you can use every shortcut which brings up a dialog - so mozilla is aware of beeing able to gain the focus again. If you don't like this, restore (any of) the minimized mozilla window(s) using mouse or Alt+Tab. ########## End of summary "May you be fixed soon" For the sake of completeness: I use mozilla from 0.9.1 on, don't know when this bug occurred first, and can reproduce it till now using 1.0RC2 BuildID 2002051006. All under Win2k.
Sorry for the above one - now try it readable... ########## Summary Even if I think comment 174 is quite right, let me sum up what I found reading nearly all comments - puh...: 1. I think comment 105 is the best way to reproduce this bug (Open one or more mozilla windows, minimize all(!), and open another one - it's locked) and, as stated there, simple and may gives the best insight into the real problem! 2. The fastest workaround (for keyboard users only ;-) when using browser is from comment 123 (using Ctrl+Shift+L followed by ESC). Generally you can use every shortcut which brings up a dialog - so mozilla is aware of beeing able to gain the focus again. If you don't like this, restore (any of) the minimized mozilla window(s) using mouse or Alt+Tab. ########## End of summary "May you be fixed soon" For the sake of completeness: I use mozilla from 0.9.1 on, don't know when this bug occurred first, and can reproduce it till now using 1.0RC2 BuildID 2002051006. All under Win2k.
Though the symptoms are similar, it seems like this is not related to bug 90337.
There are now at least three apparent duplicates of this bug - 131627, 142470 and 118360, indicating (as well as the votes for this one) how much of a pain it is. This isn't just another interface glitch - the browser becomes effectively unusable, apart from bookmarked pages. Most users will not read the workarounds here - they will give up and go back to IE. An essential one to fix before the 1.0 release.
I've been tracking this bug for over 6 months, and I see lots of good posts about how to reproduce it but little or no posts about attempts to fix it. It would be refreshing to hear from whomever is actually working on this.
Uh, look at the patch in this bug that fixes some of the cases. There are several issues that cause this to happen that are different across platforms. There are patches in the works like the one attached to this bug. If you want to help, please test it.
The patch mentioned does fix the case for which I originally filed this bug! ( Steps listed in comment #93 ) Saari: Is there any chance that patch could get checked in, and then any existing testcases that still remain could get filed as new bugs perhaps? This one seems to be getting a bit unwieldy.
*** Bug 144227 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
Imo, the proposed patch does fix the ugliest form of this bug, i.e. when there are no browser windows, mail client is minimized and you open a browser window from a shortcut (see comment #74). I am wholeheartedly suggesting to check this patch into trunk AND 1.0 branch, asap. Saari, congratulations. Great job!
Blocks: 143047
Whiteboard: [ADT2 RTM] [ETA 06/04]
Target Milestone: mozilla1.0 → mozilla1.0.1
forgive me for being a bugzilla n00b... Does the change in target milestone from 1.0 to 1.0.1 mean that 1.0 is planned to be released with this horrid bug still in? Also, where are there some explainations of what [ADT2 RTM] means? (just to satisfy my own curiosity)
mozilla 1.0 is pretty well locked down, 1.0.1 will follow shortly
> Does the change in target milestone from 1.0 to 1.0.1 mean that 1.0 is planned > to be released with this horrid bug still in? yes. before you start to complain: Mozilla1.0 is VERY close. one has to see, how long it takes to fix this bug and how risky it would be to include the patch. the patch somewhere above is rather old already and might cause unforseeable problems with not enough time left to fix them. > Also, where are there some explainations of what [ADT2 RTM] means? (just to > satisfy my own curiosity) I am not an expert here either. Things like ADT usually mean a given Netscape internal deadline. One can nominate a bug for a this deadline. The number describes the priority after the latest triaging of the bugs and changes regularily. 2 is a rather high priority I think. RTM means 'ready to manufacture' or with other words it should be included in the next version of Netscape. Since Netscape7 RC1 was released recently I guess this bug is intended to be fixed in Netscape7, which comes pretty close after Mozilla1.0 I guess. So even if Mozilla 1.0 won't have a fix for this bug, the world doesn't end. It will be fixed very soon after that...
*** Bug 146563 has been marked as a duplicate of this bug. ***
Hate to say this, but PLEASE fix this darn bug before releasing 1.0. This is worst than the annoying Download Manager, and minimize bug combined.
Yes, a mozilla with this damned bug does not qualify for 1.0 as outlined in the manifesto. What is still missing is the Mozilla1.0 KEYWORD, not only the target milestone ! 1.0 should be halted until this bug is fixed (maybe that concentrates more manpower on this one).
Why bother calling the upcoming release 1.0, with a bug this awful? Lot's of people are going to download this thing just because it's 1.0, and they'll be disgusted and turned off by a bug this blatent and frequent. Call it rc3 and at least fix this stinker before going pulling out the 1.0 name.
Apparently the plan of the powers that be is to include this bug with the 1.0 release. For what it's worth I want to voice my strong objection against it. I recommended Mozilla to a couple of people and every single one of them asked me about this bug within a couple of days using it. I can understand that this bug might be hard to fix because a lot of work has to go into fixing it and testing the fix but I'd rather postpone the 1.0 relase. This bug is highly visible. As long as the version number starts with an 0 or at least says RC people are willing to accept this. With leaving this bug in 1.0 the development team risks credibility because people will point at the manifesto. I know 1.0 is almost locked down but please at least consider postponing it for this bug.
The workarounds to this issue are unreasonable for end users to deal with and the blatency of the problem will undermine the entire Mozilla effort. I'm amazed the problem has lasted this long -- been there since, what, .94? Please fix this problem before 1.0.
Please correct this now ! Or this project will be doomed.
RC3 on Win98 still shows this bug. (Open Mozilla, minimise, click on desktop icon to open Mozilla again and most times the bug shows). Major usability hassles like this should be fixed before 1.0 is released.
The workaround for this needs to be in the release notes(if there is an agreed upon workaround, minimize/restore always works for me). I imagine the average user will get pretty frustrated when they cant type in the URL bar, but then again the average user might not read the release notes.
Netscape 7.0 Preview Release 1 is having the exact same bug. Launch the browser, minimize it, launch a new copy of the browser, and while on focus the address bar is "locked". Remember to not use a "HOME" web-address that opens a popup-window or anything like that.
Out of comments from comment 184 onwards, only /one/ has been at all useful (comment 195). Again, people, look at the roadmap to see what mozilla1.0.1 means. Think about what ranting in this bug is doing - does it help fix the bug ? No. Instead of whining, how about reading comment 180 and actually helping out ?
It is not that we are complaining. We just feel, Mozilla owes it to its testers to fix this bug before the 1.0 version is released. If we are going to recommend this official commercial product, it should be up to a standard where a simple URL form works on it.
Remember the Netscape 6.0 fiasco? That's when NS lost credibility in the community. Well this is the Mozilla 1.0 fiasco. This is a bug that makes it stop working completely, 20 times per day. At least that is going to be the impression that new users will get, since they don't know the workarounds.
Quality controllers, where are you ?
STOP. Take it to the newsgroups.
This might help somebody who is debugging this problem. My system is Windows XP professional and I am using RC3. I can generate it consistently by first openning mail and minimizing it and immediately opening a browser window. If you close this window and open another, you don't see this again. To repeate all I have to do is to close all windows and bring up mail again.
This might help somebody who is debugging this problem. My system is Windows XP professional and I am using RC3. I can generate it consistently by first openning mail and minimizing it and immediately opening a browser window. If you close this window and open another, you don't see this again. To repeate all I have to do is to close all windows and bring up mail again.
*** Bug 147710 has been marked as a duplicate of this bug. ***
Blocks: 131007
I learned something new that may help you. I minimized a browser and then opened mail. Same problem in mail. You cannot type in the subject or sender contains field. I think that your browser or email, when one is minimized the other thinks that it is minimized and therefore text inside must be disabled. This could be some how that these windows are related to each other such as child hierarchy. This was my two cents
No longer blocks: 131007
OK. One more observation to who ever who debugs this problem. You can also conistently get this problem by minimizing one browser window and opening another browser window. This is serious. I think that you should fix this problem in the first release of mozilla or netscape 7.
The dependency on bug 131007 was nuked... is this intentional?
Thanks everyone for all the tips on how to reproduce and workarounds, but please, I think we have enough noise in this bug. This bug also has all the right graffiti so we already know how important it is and it even has an ETA. Restoring my nuked depends on Acrobat feezing bug 131007. Saari: is your patch the right fix on Windows: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=73116 Do you know what's the root cause of this problem?
Blocks: 131007
Nominating for Mozilla 1.0 by popular acclaim. It might be better, though, to wait for 1.0.1, which will probably coincide with the next major Netscape release. Proposed relnote: If typing in the URL bar does not display or input any characters, open File | Open Web Location and enter the URL in the dialog box. After loading an URL with this method, the next URL can be typed directly into the URL bar.
Keywords: mozilla1.0, relnote
*** Bug 117555 has been marked as a duplicate of this bug. ***
>Proposed relnote: If typing in the URL bar does not display or input any >characters, open File | Open Web Location and enter the URL in the dialog box. >After loading an URL with this method, the next URL can be typed directly into >the URL bar. Sounds good, but you forget that with this workaround you still cannot type any text in textboxes (forms etc.) that appear on the page that is opened via "Open Location". Instead the prposed workaround should be to switch to another window (preferrably with Alt-Tab) and then switch back.
I also experience the same no caret can't type issue and it also happens when using the: file|Open Web Location (cntl+Shift+L). I dont know if this qurick is related or not, but when this is happening I have same sort of thing going on in Preferences | History setings for :Remembering visited pages for last |_| days & :Number of pages in session history |_| boxes.
>you forget that with this workaround you still cannot type any >text in textboxes (forms etc.) that appear on the page that is opened via "Open >Location". I can't reproduce this. With one Mozilla window open, minimize. Then, double-click the Mozilla desktop icon (Windows 98). A new Mozilla window opens. Can't type in URL bar. File | Open Web Location. Type in www.google.com. Hit enter. Browser goes to Google. Can type in the search field.
*** Bug 148113 has been marked as a duplicate of this bug. ***
*** Bug 148166 has been marked as a duplicate of this bug. ***
It also happens in RC3 in things like pop-up password boxes (such as to enter your master password)! This is very annoying.
IRT comment #214, Bug 148113 refers to the F11 key not working. There is no mention any funtion keys not working in this bug (82534), however, the F11 key quits working while symptoms of (82534) are present.
*** Bug 147917 has been marked as a duplicate of this bug. ***
*** Bug 148409 has been marked as a duplicate of this bug. ***
*** Bug 148434 has been marked as a duplicate of this bug. ***
Summary: Cannot type in URL bar or text boxes - no caret. (Keyboard locks up / no input) → Cannot type in URL/address/loaction bar or text boxes - no caret/cursor. (Keyboard locks/freezes up / no input)
No longer blocks: 131007
*** Bug 131007 has been marked as a duplicate of this bug. ***
I have just marked bug 131007 as a dup. Please read comment #9 there containing some event debugging. If you think it is not related please reopen 131007 and explain. The problem is easily reproduceable and may be worth giving steps here: 1. have Acrobat plugin in your Plugins folder 2. load big pdf: http://access.adobe.com/cgi-bin/browser/nobs/browser/cookbook.pdf 3. while it is loading left click in the browser window 4. the whole thing is now no longer responsive to anything Right click or switching to a different application and back helps.
Blocks: 131007
*** Bug 148595 has been marked as a duplicate of this bug. ***
I have easier workaround for W32. 1. Press windows key. That's it. This behavior reminds me of the problems I had with many programs in OS/2 days. The apps thought that alt/shift/ctrl key was being pressed and the only remedy was to go thru each of those keys until you got the right one.
This MSDN document on WM_ACTIVATE may have some useful information about the problem: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/keybinpt_3exx.asp Stating that 2 windows of the same input queue, the deactivate old and activate new are synchronized -- i.e. a window will not be activated until the other is deactivated. Also states, if a window being activated is not minimized then the DefWindowProc sets the keyboard focus to the activated window. The minimized flag appears to be ignored here: http://lxr.mozilla.org/seamonkey/source/embedding/qa/testembed/BrowserView.cpp#1038
The way to reproduce this bug on Mozilla 1.0 RC3 (Win NT 4 Wrks English + SP6a): 1) Run "disk:\path\mozilla.exe" -turbo 2) Click on Mozilla icon in taskbar to run "Mail and news" 3) Minimize "Main and news" 4) Click on Mozilla icon in taskbar to run Browser. 5) You can't type text in URL textbox
Mozilla 1.0 RC3 Linux This is a bug that I encounter often. I am able to reproduce it by opening a page with a login form. The "Select User" dialog box from the Password Manager pops up, I select a user or click cancel (it doesn't seem to matter) and the url box and the text boxes on the web page freeze. If I open a new Mozilla browser, the new browser works, but the original one is still frozen. If I try to create a new tab in the original browser, it is also frozen. It is only the url text box and the text boxes on the web page that freeze. All of the links on the page work, as well as other form elements (submit buttons, radio buttons...). I'd really love to help track down this bug. Let me know if there's any other information that would be useful to you.
Though one thing i might add to 82534 is the fact that i couldn't enter text into the Google search text box, and this happened at the same time. This was with Win2k and build 2002052306, but this happened with me on previous builds. Also google was set as my homepage.
*** Bug 149184 has been marked as a duplicate of this bug. ***
Mozilla RC3 Linux RedHat(Mandrake) - Gnome Enlightenment 0.16-4 I have similar problems like "Additional Comment #227" and have one more note: when url box freeze, every time helps me with unfreeze to switch to another virtual desktop and then switch back.
*** Bug 149215 has been marked as a duplicate of this bug. ***
*** Bug 131627 has been marked as a duplicate of this bug. ***
*** Bug 149136 has been marked as a duplicate of this bug. ***
With out being able to duplicate it on demand it must be rather hard to track down. It seems to happen when i'm opening a new browser, either by Control+N or by hitting the mozilla short cut. I do not belive i've seen it happen on the first instance. is there an option from the menu anywhere to have the browser send back useful data ? that may be a debuggin idea you could have something on the menu that would send you back an email with what's in current variables etc. ;) hmm.. well good luck tracking this one down. Oh Also My home browser Mozilla RC3 does not seem to use the real player plug in. i am using Real One on this machine Windows 2000 and it works well though
when I've seen the bug, it has usually been just after restoring (un-minimizing) a window.
I have the same behaviour as Comment #227 on Linux using RC3/RC2/RC1. It's 100% reproducable for me, but I've found that I can skirt the problem by changing focus to some other open application and then flipping back to Moz (I use sloppy focus follows mouse, so this is easy for me). It sure seems as though Moz doesn't realize it is the focused window (at least from a keyboard perspective). Greg
*** Bug 149449 has been marked as a duplicate of this bug. ***
*** Bug 147676 has been marked as a duplicate of this bug. ***
Verified on WinXP build 2002053012 (Release 1.0). Still can't type URL sometimes.
I just Ran into the bug, i opened a new browser with Control+N and though i could highlight the address bar i could not change the contents by typing. or by trying a paste Control+V , But then i used Alt+Tab and went to a different program and used Alt+tab to return to the browser and it then worked correctly. I've probally opened a hundred or so new windows today and that is the 1st time its happened to me on Versoin 1.0 the RC's seemed to have it happen a bit more often. i am using the Little Mozilla skin. i had 2 other mozillas open both with multiple tabs open. hope this helps.
*** Bug 149601 has been marked as a duplicate of this bug. ***
*** Bug 149884 has been marked as a duplicate of this bug. ***
*** Bug 149473 has been marked as a duplicate of this bug. ***
*** Bug 147538 has been marked as a duplicate of this bug. ***
Tim LaDuca wrote: >You misspelled "location", please fix this. > >Regards, >Tim thanx Tim. ;) when will this bug be accepted and assigned?
Summary: Cannot type in URL/address/loaction bar or text boxes - no caret/cursor. (Keyboard locks/freezes up / no input) → Cannot type in URL/address/location bar or text boxes - no caret/cursor. (Keyboard locks/freezes up / no input)
*** Bug 115356 has been marked as a duplicate of this bug. ***
*** Bug 150293 has been marked as a duplicate of this bug. ***
Bug 104561 ("Cannot Type In Text Boxes of Websites") looks similar to me; it has an interesting recent "steps-to-reproduce" comment at http://bugzilla.mozilla.org/show_bug.cgi?id=104561#c35 Also, not sure whether it's related or not, in bug 80380 I tried to narrow down a problem with not being able to type in a textfield in the file picker (though the cursor was blinking fine). See http://bugzilla.mozilla.org/show_bug.cgi?id=80380#c24 and 25.
*** Bug 150545 has been marked as a duplicate of this bug. ***
*** Bug 150557 has been marked as a duplicate of this bug. ***
*** Bug 150570 has been marked as a duplicate of this bug. ***
Updating mozilla1.0 keyword to mozilla1.0.1 keyword. Saari, is your patch still working with current builds? Can we have it in the trunk to test? Reporters: Please test the patch and comment on it instead of posting 'me too's, thank's.
Keywords: mozilla1.0 → mozilla1.0.1
Whiteboard: [ADT2 RTM] [ETA 06/04] → [ADT2 RTM] [ETA 06/04] (Don't add 'me too's, thank's!)
*** Bug 150585 has been marked as a duplicate of this bug. ***
As I had mentioned in comment #181 , the patch attached to this bug does fix the tescases. (at least on win32) Though, I think the patch is against older code. Maybe I was doing something wrong, but I had to modify the source code by hand rather than using "patch"
the patch applied ok for me (perhaps Linux patch is more tolerant), but the problem on Linux this fixed, dupe bug 130482, now works without the patch.
Andrew, bug 130482 seems to actually be a dup of bug 130581 that was worked around by disabling caching of composition windows on Linux (which is probably the reason you no longer see bug 130482). Can you check whether "Mozilla + this patch + reversal of bug 130581 patch" has bugs 130482 and 130581? If not, then we should be able to re-enable the composition window (bug 137698) once this patch lands.
Blocks: 137698
my 'version' of this bug is the one where switching to another application and back fixes it. (On Windows). Is anyone getting a 'version' of this bug where that doesn't fix it? If so maybe there should be two distinct bugs.
Whiteboard: [ADT2 RTM] [ETA 06/04] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/10] (Don't add 'me too's, thank's!)
raising impact.
*** Bug 137486 has been marked as a duplicate of this bug. ***
*** Bug 150904 has been marked as a duplicate of this bug. ***
*** Bug 150896 has been marked as a duplicate of this bug. ***
*** Bug 150954 has been marked as a duplicate of this bug. ***
Whiteboard: [ADT1 RTM] [ETA 06/10] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/17] (Don't add 'me too's, thank's!)
*** Bug 151679 has been marked as a duplicate of this bug. ***
*** Bug 152237 has been marked as a duplicate of this bug. ***
*** Bug 152321 has been marked as a duplicate of this bug. ***
*** Bug 145567 has been marked as a duplicate of this bug. ***
*** Bug 140413 has been marked as a duplicate of this bug. ***
*** Bug 141675 has been marked as a duplicate of this bug. ***
*** Bug 152466 has been marked as a duplicate of this bug. ***
Chris, do you have a new ETA for this?
just need to get reviews and land
Attachment #73116 - Attachment is obsolete: true
Attachment #88236 - Flags: superreview+
Comment on attachment 88236 [details] [diff] [review] fixed spacing in the patch sr=jag pending testing on Win98 and cleaning up those tabs in nsWindow.cpp
Comment on attachment 88236 [details] [diff] [review] fixed spacing in the patch r=bryner
Attachment #88236 - Flags: review+
let's get this landed on trunk asap, so that we can get it verified and on the 1.0 branch ... making oh so many folks very, very happy. thanks for the fix chris.
Keywords: adt1.0.1, approval
Whiteboard: [ADT1 RTM] [ETA 06/17] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/21] (Don't add 'me too's, thank's!)
*** Bug 148202 has been marked as a duplicate of this bug. ***
patch in trunk for win32 (the only platform it addressed)
paul - sujay is out on vacation. who can verify this fix tomorrow?
i'll check this out with tomorrow's trunk bits on win2k...
QA Contact: sujay → sairuh
so far this looks good with today's 2002.06.20.08 commercial trunk build on win2k. tests ran: * blake's test in comment 82. * focus in content (sanity check): links in new window and new tab work fine. * focus and typing in urlbar (more sanity checks): new (blank) tab, ctrl+L, clicking into urlbar...all work fine.
Whiteboard: [ADT1 RTM] [ETA 06/21] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/21] [verified on win32 trunk] (Don't add 'me too's, thank's!)
adt1.0.1+ on behalf of the adt, pending drivers' approval. pls check in to the 1.0 branch asap, and add the fixed1.0.1 keyword.
Keywords: adt1.0.1 → adt1.0.1+
> ---- Additional Comment #180 From saari@netscape.com 2002-05-21 11:16 ---- > Uh, look at the patch in this bug that fixes some of the cases. There are > several issues that cause this to happen that are different across platforms. --- Additional Comment #277 From saari@netscape.com 2002-06-19 22:10 ---- > patch in trunk for win32 (the only platform it addressed) --- Additional Comment #281 From Jaime Rodriguez, Jr. 2002-06-20 11:45 --- > adt1.0.1+ on behalf of the adt, pending drivers' approval. pls check in to the > 1.0 branch asap, and add the fixed1.0.1 keyword. Please compare the 3 cites comments. Marking this fixed now does not make sense.
Could some of the reported problems here and in the dups be due to bug 103197?
For me it appears when the mail client window is opened and only when it is opened. I can solve the problem by reducing the mail window. After that, I'm able to enter some text in the url or in the forms
IT does look like this bug could be related to Bug 103197. In that the browser is missing when certain areas get focus, or aparent focus. I actually thought this bug accured less for me on version 1.0 then any of the builds after that. though i'm currently on a now over 1 day build. shame on me. When I get the Bug i usually get it 2-4 times in a row.
Some statistics on this bug: 44 Win32 duplicates (of them, 1 seems completely unrelated, 2 are related to acrobat plugin). 12 Linux duplicates (two of them seem unrelated) 3 Mac duplicates, (one of them might be unrelated). Last Mac related comment was added on 2001-12-29. I don't think we can get out of this over-bloated bug while it keeps to be "Platform:All". Excessive number of comments and testcases, many of them about a variety of probably unrelated issues. Suggesting to set Platform->Linux and file new bugs for possible Win32 cases left unsolved by the last patch.
definitely break this apart based on platform. There is a totoally different fix for OSX for example, and I suspect the same for linux.
To further support saari's last comment, I am correcting my previous statistics (I was fooled by counting on an semi-loaded page). There are 70 Win32 duplicates, 16 for Linux, 5 for Mac, 2 Win/Linux. Last Mac comment was added on May.
this has been checked into the trunk. resolving as fixed. sairuh - let's get this verified, so we can take this on the branch today.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: [ADT1 RTM] [ETA 06/21] [verified on win32 trunk] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/24] [verified on win32 trunk] (Don't add 'me too's, thank's!)
jaime, i already verified this yesterday on the trunk --see comment 280 and the whiteboard status. will mark this as "verified". again, this was only for win32, as saari has been indicating.
Status: RESOLVED → VERIFIED
*** Bug 151976 has been marked as a duplicate of this bug. ***
*** Bug 153631 has been marked as a duplicate of this bug. ***
So, could you (saari, jamie or sairuh) please file the appropriate bugs for the other platforms, then, if you want to close this one?
*** Bug 153730 has been marked as a duplicate of this bug. ***
*** Bug 154118 has been marked as a duplicate of this bug. ***
Attachment #88236 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
Whiteboard: [ADT1 RTM] [ETA 06/24] [verified on win32 trunk] (Don't add 'me too's, thank's!) → [ADT1 RTM] [ETA 06/26] [verified on win32 trunk] (Don't add 'me too's, thank's!)
*** Bug 154372 has been marked as a duplicate of this bug. ***
Has the win32 patch been checked into the branch yet? If not, please check this in.
*** Bug 155074 has been marked as a duplicate of this bug. ***
*** Bug 155268 has been marked as a duplicate of this bug. ***
*** Bug 144581 has been marked as a duplicate of this bug. ***
I had another bug that had a specific testcase to reproduce something similar to this: http://bugzilla.mozilla.org/show_bug.cgi?id=127741 same bug?
Has this bug been fixed in the 1.1a release?
Rob: no. the fix got checked in to the trunk on June 21st - 1.1a was released back on June 11th. the fix (which is apparently windows only) will be in the 1.0.1 release, and also 1.1beta. if you want to check out a fixed version, download a nightly build (see http://www.mozilla.org for details)
vrfy'd fixed on the branch using 2002.07.02.08-1.0 comm bits on win2k.
Keywords: fixed1.0.1 → verified1.0.1
*** Bug 155605 has been marked as a duplicate of this bug. ***
Alias: caret
*** Bug 155669 has been marked as a duplicate of this bug. ***
*** Bug 155946 has been marked as a duplicate of this bug. ***
*** Bug 156076 has been marked as a duplicate of this bug. ***
*** Bug 156144 has been marked as a duplicate of this bug. ***
*** Bug 156295 has been marked as a duplicate of this bug. ***
*** Bug 157021 has been marked as a duplicate of this bug. ***
*** Bug 157086 has been marked as a duplicate of this bug. ***
*** Bug 157140 has been marked as a duplicate of this bug. ***
*** Bug 157194 has been marked as a duplicate of this bug. ***
This is occuring again on Win XP Build 20020708 always reproed with a new window/tab. I don't see the caret but once I start typing, all the key strokes get sent to the url bar.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 156946 has been marked as a duplicate of this bug. ***
*** Bug 157259 has been marked as a duplicate of this bug. ***
*** Bug 157280 has been marked as a duplicate of this bug. ***
Manoj Mehta, are you still seeing the problem that made you reopening this bug? Can't reproduce on Win2K, 2002071208 and I have no reasons to believe that WinXP handles focus in a different way than Win2K.
This happens a lot less often for me now in recent builds than it used it seems, but I still do experience it every now and then. I noticed it in a form input field the other day in a current 1.1 build.
> This happens a lot less often for me now in recent > builds than it used it seems, but I still do > experience it every now and then. I noticed it in a > form input field the other day in a current 1.1 build. Well, I have been experiencing it a lot if Linux (2002070204). Installed on Gentoo. Doesn't happen a lot in XP. Ajay Gautam
*** Bug 157352 has been marked as a duplicate of this bug. ***
I have Mozilla Gecko/20020530 running on WinNT 2000. When I clicked on a link in Outlook 2000, it opened up my Mozilla window like it should. But I could not click in the location bar to type in an address. croberts@gilsongraphics.com (new address)
UPDATE: After updating this bug I went back to the window that Outlook had opened and I could then enter something in the location bar. Weird. p.s. My last msg should read "When I clicked on a link in an Outlook 2000 email..."
I have this with build 2002071606 on my FreeBSD box. After a seamingly random period mozilla stops reacting to the keyboard. Mouse does still work. Cannot type in forms either. Restarting the windowmanager and then mozilla fixes the problem.
*** Bug 157705 has been marked as a duplicate of this bug. ***
I've tried 0.9.4, 1.0 and now even 1.1a and can reproduce this problem very consistently. The browser URL field and any other html form text fields are non-editable... unless you switch to another window and come back (sometimes you have to try this a few times to get them to work again incidentally). This seems to be a problem in all of the Win2K JRE's 1.3.1-b24, 1.3.1_04, 1.4.0-b02 and 1.4.1-beta-b14 and all with out success. I have a Swing based menu system embedded in a JApplet with menu links that do a showDocument to show a URL in the target _self or in an IFrame and other menu links which do various JSObject calls. These always result in the text fields locking up. Note that I've tried an AWT based menu system that doesn't seem to have a problem and leaves text fields editable (not a lot of testing has been done to confirm that mind you). Under IE5 & 6 with the above mentioned JRE's everything works. Under NS6x with Solaris, HPUX and AIX everything seems ok with respect to text fields not locking. Seems like this is just a Win/Moz problem unfortunately since NS inherits this bug as well.
Please don't add any more comments on how to reproduce this to this bug report. Submit new bugs about this, after making sure that: * You're using a new build from ftp://ftp.mozilla.org/pub/mozilla/nightly/latest or ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-1.0 * You can reproduce it reliably (please try hard to make it reproducable). Ideally you can reproduce it on different machines, ask a colleague whether you could use her/his computer to test it. * Make it clear that your bug is a spin off from this one, else it'll get marked as a duplicate of this one. * Be sure to include all relevant information, including platform, build ID, URL and testcase if possible. * If your system has some oddities, try to reproduce the bug with and without those. * After submitting the new bug, add a comment with a reference to it here. Thank's for your efforts to make mozilla a better browser.
To Sven Resch and other users of Mozilla 1.1a: please remember that this bug has been actually fixed for Windows since 21 June 2002. Thus, Mozilla 1.0, 1.1a or any "trunk" build earlier than the above date does NOT include the fix. All the subsequent duplicates you see are bug reports for builds that don't include the fix.
Even with the "fix", it still happens thou it seems to happen less often. So the "subsequent duplicates" are not all for people running old builds as the problem is still current.
First of all, my comment had the meaning of preventing old build users from adding comments to this bug (and suggesting them to download a recent build). Second, please do your math before correcting my observations. Since I like statistics (sometimes) I'll provide you some numbers: after sairuh checked in the fix into trunk there were 23 duplicates. Of them (leaving out one Mac related dupe, since the fix is Win32 only) - 3 were using an undefined build (likely a milestone, since the users of nightlies are aware of the version system) - 18 were using builds without the fix (1 was using branch build, see bug 155268) - only 1 was using build with the fix (under WinXP). That is bug 157194 which is a different case (menu usage) and was commented as wfm. You can't reproduce that bug, using the steps provided there.
I've just filed another bug on a weird URL bar behavior (that does not seems to be a dup of this bug) - bug 158030. Is it related to this one?
A "lost carret" problem might be related to the bug under discussion. I got it using 20020716 on win2k. 1. open mozilla window 2. click on the URL bar, the carret will be blinking 3. press and releas ALT key, the carret is gone and the "file" menu item highlighted 4. press down-arrow key to get the menu-list of "file" 5. press ESC key to dismiss the menuu-list 6. use mouse to click on the URL bar. The carret is not back. You can still type in URLs and go to them. The "missing carret" problem is minor and doesn't prevent you from using the browser. - just a clue if it can help.
as a reply to #321, I just got this bug to repro on build 2002071813. But as I have said always, I just don't see the caret, but i can type into the url bar and the characters emerge, but no caret Steps to repro: 1. Open a new window. Window usually has caret flashing away in the location bar 2. Open any menu (mouse or alt+F/V/E) 3. Close the menu and click on the url bar. No caret. But I can type in the URL bar and the textfield accepts my input.
^^^^^^^^^^ READ COMMENTS #287 AND #330 BEFORE ADDING MORE COMMENTS ^^^^^^^^^^^ |||||||||| ******************************************************* ||||||||||| I hope this is enough visible. Your help on reproducing this bug was very welcome, but *no one* will be able to work on this bug with hundreds of comments and issues that are partly fixed. Therefore open *new* bugs limited to one issue as stated in comments #c187 and #c330. I won't open these bugs for you because I've never seen them using mozilla. And be sure to follow the steps in comment #330. ^^^^^^^^^^ READ COMMENTS #287 AND #330 BEFORE ADDING MORE COMMENTS ^^^^^^^^^^^ |||||||||| ******************************************************* |||||||||||
Whiteboard: [ADT1 RTM] [ETA 06/26] [verified on win32 trunk] (Don't add 'me too's, thank's!) → *Read* comments #287 and #330 first! [ADT1 RTM] [ETA 06/26] [verified on win32 trunk]
*** Bug 158262 has been marked as a duplicate of this bug. ***
Same bug on my end. I even get it when Mozilla is the only browser open, and therefore I cannot "switch" to another browser to see if the problem goes away. I've tested this on W2K, and XP. This is for Mozilla 1.0
This bug frequently occurs for me on Linux Mozilla 1.0 and 1.1. It seems to happen most in the Blackbox or Fluxbox window manager and less frequently in KDE. It seems I can no longer type in form text boxes or in the location bar if a dialog box pops up (i.e. domain not found etc.). This behavior effects all opened tabs but not new windows. Also, it seems I can sometimes regain functionality by either minimizing and then maximizing the window or by moving any windows that are behind it. Or a combination of the two. Most times however I have to close the window and start again. In my experience its as though the window loses focus but never can fully regain it.
*** Bug 159550 has been marked as a duplicate of this bug. ***
I can reproduce this easily - set the home page to "http://" and open the browser. It does it at least 10% of the time.
Workaround: Open the "find in this page" box and close it again.
*** Bug 151415 has been marked as a duplicate of this bug. ***
*** Bug 159684 has been marked as a duplicate of this bug. ***
*** Bug 160138 has been marked as a duplicate of this bug. ***
*** Bug 160330 has been marked as a duplicate of this bug. ***
*** Bug 150722 has been marked as a duplicate of this bug. ***
*** Bug 156331 has been marked as a duplicate of this bug. ***
*** Bug 161280 has been marked as a duplicate of this bug. ***
Some new clues i noticed. - I stoped using Quick launch and never got this typing problem again (quick launch is flawless here in WinNT) and i use mozilla 8h a day (webmaster job) so i don't think its just "luck" - When it used to happen here, everything worked just fine. Only that i cannot type in the url text area (i could click on the arrow on its right and click go, but not type or select text). In the page, forms worked fine, i could scroll the page with the keyboard even type email. - since i use the browser and email a lot, i just double click the quick launch icon on the systray to lauch a new browser window (Now i stoped using quick lauch, i Ctrl+1 in the email) and thats the trick, the no-typing glitch always showed up when i double clicked the auto launch icon! - to be able to type again, i click on the auto launch icon, see the menu open, and click somewhere else, kinda of to get the focus rid of it, and then i was able to type again! dunno if it's really related or it's just a coincidence. Maybe it's the problem on windows machines. I'm using: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b) Gecko/20020721
I was under the impression that I'd fixed all the quicklaunch cases. Did you see that with a recent build?
What I see since August biulds is: open a new window, trying to type smth in URLbar at text area and the browser feels like CTRL or ALT is pressed. No input, but pressing some keys loads some pages I was on sometime ago... Is this smth different?
*** Bug 161895 has been marked as a duplicate of this bug. ***
*** Bug 163758 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
Can't type different file in same site after editing and moving to a different file. Sometimes going to "go" and loaded a couple of pages back will let you type again, then it freezes up again . I'm using build 2002081506 doug r spamred@shaw.ca (Not a developer, but a Mozilla fan)
*** Bug 164542 has been marked as a duplicate of this bug. ***
I had this problem all the time ;-). (with mozilla 1 Nt 2000) I always go to type a URL in as the first thing I do an 1 time in 4 Navigator would freeze. BUT. Since installing Mozilla 1.1 on NT 2000 the problem appears to be resolved.
*** Bug 116770 has been marked as a duplicate of this bug. ***
*** Bug 166154 has been marked as a duplicate of this bug. ***
For me this is gone with Mozilla 1.1 - 20020826 (using Win2K). Testcase from comment 105 works too.
Platform Mac OS X - only bug now (bug 166154) ?
I still noticed this on W2K and XP, thou not nearly as often as it originally was.
Here is a way to ALWAYS reproduce the bug: - Minimize Mozilla - On the toolbar, close the application using the right-click menu with the mouse - Restart Mozilla and try entering something in the URL... Environment: - Win2k - Mozilla 1.0 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020529) I will install 1.1 to see if the bug still exists.
Comment to Comment #364: Doesn't work on my machine. Mozilla 1.1, W2k SP3
Bug showed itself in final release Netscape 7. Mac 8.6, 8100 with 266mh G3, 128 mb ram. Browser on all day, left machine for 2 hrs, come back and keyboard frozen.
I have this problem too. But here the conditions are a little different. The problem occurs the first time I get a dialogue/alert box. Then I can't type anything, and the cursor doesn't appear in text fields (incl. location bar) and I can't get another dialogue/alert box. I'm using mozilla 1.1 on Linux (Newest debian-package - 2:1.1-1)
I see the same under mac os 9.1 and 10.1.5. Involves a lot of fill in forms. I also feel it is a focus issue and wonder if the failure of the page up/down keys is related. However I note that hitting the 'escape' key often pulls focus back to the current page/frame and I can continue typing.
I have also experienced this problem since at least 0.97, continuing through many snapshots (mostly debian/sid mozilla-snapshot packages) as well as 1.0, 1.1, and the latest nightly snapshots from the last two nights. In some older builds I could solve the problem by typing some jibberish into another window, but this no longer seems to work. I usually have to shut down and start mozilla, or at least close the active window and open another (i.e. text input does not die in all windows, but cannot be recovered in the window). -Justin
FILE is divided into two sections, In the bank login page search for SortCodefirstTwo which is an immediately accessible field. In the bank funds transfer page the AmountNonZeroFormated field is not clickable
Here's how I am able to get it to do this 98% of the time. First the basic stats: Win2k Pro Mozilla Build 2002053012 (I haven't tried it with a more recient build, but I will) Using the Quick Launch feature, right click on the Mozilla icon in my system tray. Select Navigator. Window pops up. URL bar unresponsive, any form object (textboxes, drop down, listes, option buttons, buttons) all unresponsive. Links are OK and respond, toolbar buttons are OK and respond, Sidebar links OK and respond. It also happens when selecting the Navigator option under the Windows menu from the mail client. Also happens when double clicking on icon on desktop. It's been my experience that the length f time the window is open doesn't seem to affect this behavior. I have not had this problem in the middle of a session, only when starting. I find that I have to close the web browser and open it back up (sometimes as many as 5 or 6 times) to get one that "operates". I just got the 1.0.1 release and will install it to see if that fixed my problem.
Just because nobody seems to read bugs before commenting... Here I go again: ############################################################################### @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Please don't add any more comments on how to reproduce this to this bug report. Submit new bugs about this, after making sure that: * You're using a new build from ftp://ftp.mozilla.org/pub/mozilla/nightly/latest * You can reproduce it reliably (please try hard to make it reproducable). Ideally you can reproduce it on different machines, ask a colleague whether you could use her/his computer to test it. * Make it clear that your bug is a spin off from this one, else it'll get marked as a duplicate of this one. * Be sure to include all relevant information, including platform, build ID, URL and testcase if possible. * If your system has some oddities, try to reproduce the bug with and without those. * After submitting the new bug, add a comment with a reference to it here. Thank's for your efforts to make mozilla a better browser. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ############################################################################### Nobody can work on a bug with more than 370 comments all saying something slightly different. Thanks for testing mozilla.
*** Bug 165141 has been marked as a duplicate of this bug. ***
Ususally happens after launching. I find it's intermittent. Sometimes the browser works fine other times it locks up. I sometimes notice the browser freezing if you try to type in a new address in the address bar before the browser completely finishes loading a page. Sometimes it says the bottom left message bar of the browser that it is still loading some page but the page looks like it's already done. It is totally annoying and major problem. As soon as the browser (Netscape 7) locks up the only way to get out of it is to do a force quit. I use a G3 with OS 9.1
Keywords: mozilla1.2, mozilla1.3
I have noticed this problem only when running quicktime .mpegs and I try to change the url after watching 2 movies consecutively in the same window. I am running OS X 10.2. I can get the caret to reappear by hitting "home" and then back. Thanks
*** Bug 181793 has been marked as a duplicate of this bug. ***
*** Bug 146047 has been marked as a duplicate of this bug. ***
*** Bug 183166 has been marked as a duplicate of this bug. ***
*** Bug 169671 has been marked as a duplicate of this bug. ***
I have been bangin' my head against a wall ever since 1.1. I am running HP Tur64 UNIX Version 5.1B on an Alpha EV5 processor. I was originally told that this was a problem with my graphics setup as I am running KDE over a 4-screen panoramiX setup (with plenty of swap space I can assure you ;-)). Anyway, the problem was that I would run the current mozilla (1.1, 1.2b, 1.2, 1.2.1) and no matter what, I wouldn't be able to type anything anywhere - not the address bar - not in any mail window - nowhere. I had tried using the version of Netscape 6 that comes with V5.1B and I knew that worked. I even tried copying all of the shared libraries from the /usr/opt/netscape6/gnome/lib directory to the mozilla/gnome/lib directory - with no success. Finally, I mentioned it to someone else with a similar configuration and he told me to turn off num lock. Once I turned it off - mozilla immediately responded. Now, I can readily reproduce the problem by just turning num lock on and off. It really annoying as I am very accusomed to using the number pad to enter password and other information. Anyway, just thought this info might be useful.
Jared: what you described is not the problem I reported: my problem was that most of times when I started mozilla, the URL text box wasn't focused (I wanted to start typing URL as soon as I mozilla started), so mine was very minor compared to yours, and it only was happening in mozilla 1.2 release and up. I reverted back to 1.1 and I'm fine.
Marek: What you're describing is not this bug. This bug is not being able to focus for example the URLBar even when clicking it. No Cursor appears. This issue has been fixed for quite a while... at least on Win32.
removed me from CC because of incessantly (useless?) comments though Comment #372
I get this a LOT when going to sites that have layers and js menus - www.csuhayward.edu's template causes this almost every time I accidentally run over one of the menus and try to go to form elements. I'm developing form-based apps, and can barely test anything before all of a sudden nothing works. It's about 10x worse in 1.2.1 than it was in any other version thus far - at least 20x today, I've had this problem. -Shaun Keenan CSU Hayward
I cannot reproduce it on my Mac build at www.csuhayward.edu What platform and build do you see this happening on? (sorry, I don't have HPUX handy)
I haven't been able to reproduce this on Linux since I started using 1.2.x series. It was very visible in 1.0.1.
I've been seeing this a lot on recent (past ~2 weeks) Phoenix nightly builds on WinXP, even on a clean install.
ok, I fully realise that adding comments to this bloated page may be useless, but I can't reproduce this well enough to open a new bug. still, it's an irritating bugger that's keeping me from using Mozilla as anything more than a frustrating curiosity, so I want to at least leave a comment *somewhere*. My experience is this: I launch Mozilla (browser only), use it for as little as 5 minutes (don't know how many pages visited), and at some point it ceases to acknowledge the keyboard. Other apps are fine, and I can still click in a form input window or the URL bar and see a cursor, or at least the URL turns blue as if selected, but any keyboard activity is ignored. (This includes PgUp/Dn navigation as well as functions like Cmd-N to open a new window.) If I do open a new window, I can then use the keyboard in it, but (IIRC) not back in the original window. My browser configuration is simple and the web pages I visited were also simple. Browser: four nav buttons (Back/Fwd/Reload/Stop), URL bar, and 1-3 tabbed windows. Web pages: nothing more complicated than some HTML tables, perhaps one or two form fields, and only minor JavaScript. (example: browsing the forums on http://dealmac.com/forums/) No CSS, layers, plug-ins, or what have you. Today it happened while browsing eBay - a little more complex but not much. After seeing this repeatedly in 1.1 and deleting Mozilla in frustration, I excitedly tried 1.2b, and now 1.2.1, only to find the same problem reoccur. I guess it's good that this is possibly a cross-platform issue, making it less obscure; but it may be hard to reproduce, which is a b*tch. thanks. Platform: Mac OS 9.1, PowerMac G3 (beige) minitower, 384M RAM, 28830k allocated to Mozilla. Browser version(s): Mozilla 1.1, 1.2b, and most recently 1.2.1 ("Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2.1) Gecko/20021130"), each with only Navigator installed, and only two plug-ins (Mac Runtime for Java and Shockwave).
*** Bug 184026 has been marked as a duplicate of this bug. ***
When I try to type an address in the bar mozilla closes as soon as i hit enter.
When I try to type an address in the bar mozilla closes as soon as i hit enter.
I think this might be a focus bug. For me, this happens most often when Mozilla Mail displays a password entry dialog for the mail server. I realize this is Mail, and not the browser, but they share a common GUI and this problem seems to occasionally happen on both. It just is reproducible for me much more often in Mail and not in the browser. The password entry text box, which should have the focus by default, does not have the focus. No cursor appears, and even if keys are pressed, no characters will show up in the text box. Because it is not focused, it will not accept input. Surprisingly, even if the mouse is clicked in the text box, focus will not be given to the text box. The workaround is to press the Cancel button but drag the mouse away from the button before letting go. This will shift the focus to the Cancel button without activating it. Now, the text box will "wake up", and it will now participate in normal focus actions (you can hit Tab to give it focus, or click the mouse button on it, and so on). After given focus, it properly accepts keyboard input. I think that somehow text boxes aren't being given proper focus when the window first appears.
The focus bug Krellan describes above sounds like the race condition described in bug 103197 which people have been working around in their dialogs by using setTimeout(0) calls.
What was described in comment #392 seems to be a completely different issue. I personally have never seen it. This record is about a rather different bug, or possibly about two separate ones. Until mozilla 1.2, there was an issue where the URL field would not accept text input. This would happen randomly and the only solution was to close the window or to toggle tabs. After 1.2 this bug disappered, but was replaced by very similar one: sometimes if you press Ctrl-L, the URL text gets highlighted but doesn't accept text input. If you CLICK into it after that it does accept text. (Hence, it appears to be a somewhat separate issue to me.) This bug has been present in every build of mozilla that I have tried, both on Win2k and Linux. However, it is impossible to reproduced. I tried find a page, or the state of the browser that would reproduce this 100%, but haven't had any success. Sometimes it happens, sometimes it doesn't, regardless of what page it is, and whatever state the browser happens to be. Activating type-ahead by typing text after the page is loaded seems to increase the probability, however it is neither necessary nor sufficient.
Is this related to the bug at nvidia.com? Go to nvidia.com and try to type somthing into the "search" input box at top right - you can't.
I first saw this in 1.3a (never in 1.1) on an Apple PowerBook running MacOS 9.2 only when using Adobe PDFwriter to "print" to a PDF file. Could not type into the filename text box even though it opened with the default name "untitled" selected and the cursor worked in the box. Symbols typed on the keyboard seemed to be misdirected to the non-selected Mozilla window underneath (e.g., typing tab moved the highlight around; certain letters would appear or trigger actions).
*** Bug 150331 has been marked as a duplicate of this bug. ***
It happens also to me (always! no matter the page i'm in), and I use Win 1.3a. All the URL bar's text became highlightened, and I cannot set the cursor anywhere to INSERT text, no matter how many times I click there. However I'm able to digit, but all the previous text will be obviously REPLACED. The insert cursor always appears, too. Temporary workaround: highlight the URL in the location bar, and press an arrow key to move the insert cursor in the location bar. You can also use the End key. Then the mouse will let you to positionate the cursor where you want. Ah, sometimes it happens on forms also, but not always. Maybe it's all related to Comment #392. If not, that's another bug, so tell me which it is, for I want it resolved. Followed the Comment #330, though. But I'm not sure if this is a real *new* bug, so I don't want people to mess around searching a duplicate for their whole lifetime. If you're sure it is a real *new* bug, then say it to me.
"highlight the URL in the location bar..." If you can highlight the URLbar, then that's a different bug than this one. Why is this bug reopened anyway? The issue for which I originally filed this bug for has been fixed, and I have not seen it happen since that fix was landed. It has also grown beyond the point of being manageable. If you have a bug which seems similar to this bug, make sure it's not filed elsewhere and file a new bug report. Resolving back to FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
-> Verified as per reporter. Any further work in this bug is now impossible due to its size.
Status: RESOLVED → VERIFIED
I think this is fixed also. I have not had the problem for a long time.
Hi at Bugzilla, I'm the one who initially filed the bug so I get all of you software-wizard's communication on this mailed to me, too. In my experience the bug is still as alive and kicking as it was when I first reported it. I was referring to the Mac OS 9.x version of Mozilla (running on 2 different Macs in different locations) and it's still there for me, even in the latest build: True, very rarely now I'm not able to type in the URL-location-bar in Mozilla itself. But Moz running in the background still freezes keyboard-input in any other app running: Copying a bit of text e.g. only works using the menu's "copy" and "paste"-commands respectively. No direct keyboard-combination e.g. "command + c" works, except on file/foldernames in the finder/desktop. It also takes commands like when I try to print from AcrobatReader as my frontmost app (freezing everything until I force quit which kills Mozilla (still in the background) instead of Reader). No typing "command + ." or hitting "enter" helps. Pity because it makes such a fine browser quite an ugly duck... Yours, Olaf Mueller zweihundertcm@yahoo.de
From the top of this bug report: " Reporter: wd@pobox.com (WD)" I'm pretty sure that's me, not you. There's no point in bickering here, though. As I had mentioned in comment #399 , if you are experiencing a bug similar to what I originally reported here, feel free to file a new bug report. This bug is, for all intents and purposes, DONE.
Yes, stop any comments on this bug. The problem never occured again with the newer releases for me. Sometimes the URL bar is only not focussed, but that has nothing to do with the original bug, where you had to close and reopen Mozilla for using. Now you can simply click into URL bar and write. PS: Why I get the mails though I can't find my mail address in CC list? I know I wrote in some time ago, but it's lost :-) If the spam on this bug doesn't stop I want to remove me ...
<spam> > Why I get the mails though I can't find my mail address in CC list? Look for a X-Bugzilla-Reason header, it'll tell you why. </spam>
*** Bug 154128 has been marked as a duplicate of this bug. ***
This bug may have gone away briefly, but it's back with a vengeance in 1.3 under Linux. Can't type in the urlbar, can't type in any textareas, can't even use keyboard shortcuts to quit. I can use the browser fine as long as I only use the mouse. I had to downgrade to 1.2 just to enter this comment.
If you've installed a build from mozilla.org to a clean (empty) directory and you've created a new profile and the problem still exists, please file a new report with steps to reproduce.
*** Bug 169845 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
Alias: caret
Blocks: 261074
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: