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)
Core
DOM: Editor
Tracking
()
VERIFIED
FIXED
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)
5.82 KB,
patch
|
bryner
:
review+
jag+mozilla
:
superreview+
jud
:
approval+
|
Details | Diff | Splinter Review |
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
Comment 1•24 years ago
|
||
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
Assignee | ||
Comment 3•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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.
Updated•24 years ago
|
OS: Windows ME → All
Comment 6•24 years ago
|
||
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
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
In the 2001051420 build it doesn't do this, however in the builds starting on
the 15th it does.
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
*** Bug 84921 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
Is it a dupe of bug 30841?
Reporter | ||
Comment 12•24 years ago
|
||
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
Comment 13•24 years ago
|
||
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].
Reporter | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
this is an editor bug, possibly a focus issue
Assignee: alecf → beppe
Component: URL Bar → Editor
QA Contact: claudius → sujay
Comment 16•24 years ago
|
||
wdormann: confirm on build 2001061304 win32 talkback installer sea trunk win98
Comment 18•24 years ago
|
||
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.
Assignee | ||
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
*** Bug 87390 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
*** Bug 87452 has been marked as a duplicate of this bug. ***
Comment 22•24 years ago
|
||
*** Bug 87479 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
*** Bug 91757 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Updated•23 years ago
|
Hardware: PC → All
Reporter | ||
Comment 24•23 years ago
|
||
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.
Assignee | ||
Comment 25•23 years ago
|
||
WD, can you give me specifics on how to reproduce that? URLs, steps, platform,
etc. Thanks.
Comment 26•23 years ago
|
||
*** Bug 92531 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
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.
Assignee | ||
Comment 28•23 years ago
|
||
->0.9.5 unless I get a way to repro this
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 29•23 years ago
|
||
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.
Reporter | ||
Comment 30•23 years ago
|
||
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.
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
*** Bug 94869 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 33•23 years ago
|
||
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
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment 34•23 years ago
|
||
Yep, I've just by chance experienced what WD describes with Linux 2001082208.
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
*** Bug 105493 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 37•23 years ago
|
||
*** Bug 108356 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 111250 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
A 100% reproducible testcase for Win32 is described in bug 111250. But no output
at JS console :(
Comment 40•23 years ago
|
||
*** Bug 111578 has been marked as a duplicate of this bug. ***
Comment 41•23 years ago
|
||
*** Bug 111521 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
*** Bug 111828 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 43•23 years ago
|
||
*** Bug 103449 has been marked as a duplicate of this bug. ***
Comment 44•23 years ago
|
||
Confirmed independent of quicklaunch (reproduceable either way).
Comment 45•23 years ago
|
||
*** Bug 112452 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
*** Bug 112601 has been marked as a duplicate of this bug. ***
Comment 47•23 years ago
|
||
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.
Comment 48•23 years ago
|
||
*** Bug 100130 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
*** Bug 102008 has been marked as a duplicate of this bug. ***
Comment 50•23 years ago
|
||
*** Bug 113056 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 51•23 years ago
|
||
*** Bug 113507 has been marked as a duplicate of this bug. ***
Comment 52•23 years ago
|
||
*** Bug 114397 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Comment 53•23 years ago
|
||
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).
Comment 54•23 years ago
|
||
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.
Comment 55•23 years ago
|
||
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 ?
Comment 56•23 years ago
|
||
*** Bug 115248 has been marked as a duplicate of this bug. ***
Comment 57•23 years ago
|
||
*** Bug 116423 has been marked as a duplicate of this bug. ***
Comment 58•23 years ago
|
||
*** Bug 116726 has been marked as a duplicate of this bug. ***
Comment 59•23 years ago
|
||
*** Bug 117314 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
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.
Comment 61•23 years ago
|
||
*** Bug 117425 has been marked as a duplicate of this bug. ***
Comment 62•23 years ago
|
||
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?
Comment 63•23 years ago
|
||
"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.
Comment 64•23 years ago
|
||
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.
Comment 65•23 years ago
|
||
*** Bug 117873 has been marked as a duplicate of this bug. ***
Comment 66•23 years ago
|
||
*** Bug 115553 has been marked as a duplicate of this bug. ***
Comment 67•23 years ago
|
||
*** Bug 118543 has been marked as a duplicate of this bug. ***
Comment 68•23 years ago
|
||
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
Comment 69•23 years ago
|
||
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.
Comment 70•23 years ago
|
||
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....
Comment 71•23 years ago
|
||
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.
Comment 72•23 years ago
|
||
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').
Comment 73•23 years ago
|
||
Too much traffic...
Comment 74•23 years ago
|
||
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.
Reporter | ||
Comment 75•23 years ago
|
||
*** Bug 120290 has been marked as a duplicate of this bug. ***
Comment 76•23 years ago
|
||
*** 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)
Comment 77•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 78•23 years ago
|
||
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
Reporter | ||
Comment 79•23 years ago
|
||
Bug is still present with 2002013003 trunk build pulled at 5:40 PM EST
Comment 80•23 years ago
|
||
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.
Assignee | ||
Comment 81•23 years ago
|
||
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...
Comment 82•23 years ago
|
||
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.
Assignee | ||
Comment 83•23 years ago
|
||
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.
Assignee | ||
Comment 84•23 years ago
|
||
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).
Reporter | ||
Comment 85•23 years ago
|
||
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.
Comment 86•23 years ago
|
||
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.
Comment 87•23 years ago
|
||
Looks like this guy silently died !
WFM Release 0.9.8 Linux.
Comment 88•23 years ago
|
||
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
Reporter | ||
Comment 90•23 years ago
|
||
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 → ---
Comment 91•23 years ago
|
||
With 0.9.8 on Win2k the steps from comment #74 still reproduce this bug this for
me. Sorry, no silent death here :-(
Comment 92•23 years ago
|
||
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.
Reporter | ||
Comment 93•23 years ago
|
||
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
Comment 94•23 years ago
|
||
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 ?
Comment 95•23 years ago
|
||
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 :)
Comment 96•23 years ago
|
||
*** Bug 123838 has been marked as a duplicate of this bug. ***
Comment 97•23 years ago
|
||
*** Bug 111426 has been marked as a duplicate of this bug. ***
Comment 99•23 years ago
|
||
*** Bug 125040 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 100•23 years ago
|
||
*** Bug 125235 has been marked as a duplicate of this bug. ***
Comment 101•23 years ago
|
||
*** Bug 118399 has been marked as a duplicate of this bug. ***
Comment 102•23 years ago
|
||
*** Bug 124982 has been marked as a duplicate of this bug. ***
Comment 103•23 years ago
|
||
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.
Comment 104•23 years ago
|
||
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 ...
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
#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 ?
Comment 107•23 years ago
|
||
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.
Comment 108•23 years ago
|
||
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
Comment 109•23 years ago
|
||
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.
Comment 110•23 years ago
|
||
*** Bug 116123 has been marked as a duplicate of this bug. ***
Comment 111•23 years ago
|
||
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'.
Comment 112•23 years ago
|
||
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.
Comment 113•23 years ago
|
||
the url field goes mad usually after loading non-html pages, for example
macromedia flash (swf) files, ... (Windows 2000)
Comment 114•23 years ago
|
||
*** Bug 111417 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 115•23 years ago
|
||
Reporter | ||
Comment 116•23 years ago
|
||
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)
Comment 117•23 years ago
|
||
*** Bug 123866 has been marked as a duplicate of this bug. ***
Comment 118•23 years ago
|
||
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.
Comment 119•23 years ago
|
||
118: This works in Linux i686 0.9.8
Comment 120•23 years ago
|
||
I also have not seen a recurrence since switching to Linux 0.9.8 2002020511
Comment 121•23 years ago
|
||
*** Bug 130649 has been marked as a duplicate of this bug. ***
Comment 122•23 years ago
|
||
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)
Comment 123•23 years ago
|
||
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.
Comment 124•23 years ago
|
||
*** Bug 121681 has been marked as a duplicate of this bug. ***
Comment 125•23 years ago
|
||
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.
Comment 126•23 years ago
|
||
Confirming reproducability of Testcase on 2002032903 on W2K.
Comment 127•23 years ago
|
||
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.
Comment 128•23 years ago
|
||
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.
Comment 129•23 years ago
|
||
*** Bug 134354 has been marked as a duplicate of this bug. ***
Comment 130•23 years ago
|
||
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
Comment 131•23 years ago
|
||
*** Bug 130482 has been marked as a duplicate of this bug. ***
Comment 132•23 years ago
|
||
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?
Comment 133•23 years ago
|
||
*** Bug 134611 has been marked as a duplicate of this bug. ***
Comment 134•23 years ago
|
||
*** Bug 134938 has been marked as a duplicate of this bug. ***
Comment 135•23 years ago
|
||
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.
Comment 136•23 years ago
|
||
Addition to Comment #130:
Text boxes, input fields etc become locked for keyboard access, too.
The focus is no longer movable by keyboard.
Comment 137•23 years ago
|
||
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....?
Comment 138•23 years ago
|
||
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.
Comment 139•23 years ago
|
||
Brian,
That's bug 130581. There's two workarounds mentioned in that bug too.
Comment 140•23 years ago
|
||
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.
Comment 141•23 years ago
|
||
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
Comment 142•23 years ago
|
||
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 :(
Comment 143•23 years ago
|
||
*** Bug 135502 has been marked as a duplicate of this bug. ***
Comment 144•23 years ago
|
||
Adding myself as a cc since someone reported seeing this on OpenVMS today.
Reporter | ||
Comment 145•23 years ago
|
||
*** Bug 107077 has been marked as a duplicate of this bug. ***
Comment 146•23 years ago
|
||
More data:
Happens to me with QL on, goes away after turning it off. Build 2002-04-16-17.
Win 2k.
Comment 147•23 years ago
|
||
I'm seeing this with rc1 on Linux. This should be fixed before mozilla goes gold.
Comment 148•23 years ago
|
||
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.
Comment 149•23 years ago
|
||
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..."
Comment 150•23 years ago
|
||
#149 WFM as in #148
Comment 151•23 years ago
|
||
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>.
Comment 152•23 years ago
|
||
Also reproduced as above on Windows XP (moziilaRC1)
Comment 153•23 years ago
|
||
*** Bug 139019 has been marked as a duplicate of this bug. ***
Comment 154•23 years ago
|
||
I can reproduce this via the technique in comment #105 on Windows ME too.
(mozilla 1.0 RC1)
Comment 155•23 years ago
|
||
*** Bug 138209 has been marked as a duplicate of this bug. ***
Comment 156•23 years ago
|
||
*** Bug 139119 has been marked as a duplicate of this bug. ***
Comment 157•23 years ago
|
||
*** Bug 139216 has been marked as a duplicate of this bug. ***
Comment 158•23 years ago
|
||
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!
Comment 159•23 years ago
|
||
what about mozilla1.0+ flag?
Comment 160•23 years ago
|
||
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>
Comment 161•23 years ago
|
||
By opening a second Mozilla browser, under the Modern theme, I am able reproduce
this.
Comment 162•23 years ago
|
||
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.
Reporter | ||
Comment 163•23 years ago
|
||
*** Bug 142583 has been marked as a duplicate of this bug. ***
Comment 164•23 years ago
|
||
*** Bug 143263 has been marked as a duplicate of this bug. ***
Comment 165•23 years ago
|
||
*** Bug 143121 has been marked as a duplicate of this bug. ***
Comment 166•23 years ago
|
||
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.
Comment 167•23 years ago
|
||
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.
Comment 168•23 years ago
|
||
Happens sometimes on WinXP Eng.
Build 2002051006.
Comment 169•23 years ago
|
||
This bug is back in 1.0rc2 on Win2000. I never saw it in 1.0rc1.
Comment 170•23 years ago
|
||
*** Bug 144231 has been marked as a duplicate of this bug. ***
Comment 171•23 years ago
|
||
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.
Comment 172•23 years ago
|
||
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?
Comment 173•23 years ago
|
||
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.
Comment 174•23 years ago
|
||
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.
Comment 175•23 years ago
|
||
########## 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.
Comment 176•23 years ago
|
||
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.
Comment 177•23 years ago
|
||
Though the symptoms are similar, it seems like this is not related to bug 90337.
Comment 178•23 years ago
|
||
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.
Comment 179•23 years ago
|
||
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.
Assignee | ||
Comment 180•23 years ago
|
||
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.
Reporter | ||
Comment 181•23 years ago
|
||
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.
Assignee | ||
Comment 182•23 years ago
|
||
*** Bug 144227 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
Comment 183•23 years ago
|
||
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!
Updated•23 years ago
|
Comment 184•23 years ago
|
||
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)
Assignee | ||
Comment 185•23 years ago
|
||
mozilla 1.0 is pretty well locked down, 1.0.1 will follow shortly
Comment 186•23 years ago
|
||
> 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...
Comment 187•23 years ago
|
||
*** Bug 146563 has been marked as a duplicate of this bug. ***
Comment 188•23 years ago
|
||
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.
Comment 189•23 years ago
|
||
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).
Comment 190•23 years ago
|
||
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.
Comment 191•23 years ago
|
||
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.
Comment 192•23 years ago
|
||
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.
Comment 193•23 years ago
|
||
Please correct this now !
Or this project will be doomed.
Comment 194•23 years ago
|
||
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.
Comment 195•23 years ago
|
||
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.
Comment 196•23 years ago
|
||
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.
Comment 197•23 years ago
|
||
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 ?
Comment 198•23 years ago
|
||
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.
Comment 199•23 years ago
|
||
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.
Comment 200•23 years ago
|
||
Quality controllers, where are you ?
Reporter | ||
Comment 201•23 years ago
|
||
STOP. Take it to the newsgroups.
Comment 202•23 years ago
|
||
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.
Comment 203•23 years ago
|
||
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.
Comment 204•23 years ago
|
||
*** Bug 147710 has been marked as a duplicate of this bug. ***
Comment 205•23 years ago
|
||
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
Comment 206•23 years ago
|
||
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.
Comment 207•23 years ago
|
||
The dependency on bug 131007 was nuked... is this intentional?
Comment 208•23 years ago
|
||
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
Comment 209•23 years ago
|
||
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
Comment 210•23 years ago
|
||
*** Bug 117555 has been marked as a duplicate of this bug. ***
Comment 211•23 years ago
|
||
>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.
Comment 212•23 years ago
|
||
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.
Comment 213•23 years ago
|
||
>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.
Reporter | ||
Comment 214•23 years ago
|
||
*** Bug 148113 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 215•23 years ago
|
||
*** Bug 148166 has been marked as a duplicate of this bug. ***
Comment 216•23 years ago
|
||
It also happens in RC3 in things like pop-up password boxes (such as to enter
your master password)! This is very annoying.
Comment 217•23 years ago
|
||
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.
Comment 218•23 years ago
|
||
*** Bug 147917 has been marked as a duplicate of this bug. ***
Comment 219•23 years ago
|
||
*** Bug 148409 has been marked as a duplicate of this bug. ***
Comment 220•23 years ago
|
||
*** Bug 148434 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
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)
Comment 221•23 years ago
|
||
*** Bug 131007 has been marked as a duplicate of this bug. ***
Comment 222•23 years ago
|
||
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
Comment 223•23 years ago
|
||
*** Bug 148595 has been marked as a duplicate of this bug. ***
Comment 224•23 years ago
|
||
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.
Comment 225•23 years ago
|
||
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
Comment 226•23 years ago
|
||
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
Comment 227•23 years ago
|
||
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.
Comment 228•23 years ago
|
||
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.
Comment 229•23 years ago
|
||
*** Bug 149184 has been marked as a duplicate of this bug. ***
Comment 230•23 years ago
|
||
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.
Comment 231•23 years ago
|
||
*** Bug 149215 has been marked as a duplicate of this bug. ***
Comment 232•23 years ago
|
||
*** Bug 131627 has been marked as a duplicate of this bug. ***
Comment 233•23 years ago
|
||
*** Bug 149136 has been marked as a duplicate of this bug. ***
Comment 234•23 years ago
|
||
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
Comment 235•23 years ago
|
||
when I've seen the bug, it has usually been just after restoring (un-minimizing)
a window.
Comment 236•23 years ago
|
||
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
Comment 237•23 years ago
|
||
*** Bug 149449 has been marked as a duplicate of this bug. ***
Comment 238•23 years ago
|
||
*** Bug 147676 has been marked as a duplicate of this bug. ***
Comment 239•23 years ago
|
||
Verified on WinXP build 2002053012 (Release 1.0).
Still can't type URL sometimes.
Comment 240•23 years ago
|
||
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.
Comment 241•23 years ago
|
||
*** Bug 149601 has been marked as a duplicate of this bug. ***
Comment 242•23 years ago
|
||
*** Bug 149884 has been marked as a duplicate of this bug. ***
Comment 243•23 years ago
|
||
*** Bug 149473 has been marked as a duplicate of this bug. ***
Comment 244•23 years ago
|
||
*** Bug 147538 has been marked as a duplicate of this bug. ***
Comment 245•23 years ago
|
||
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)
Comment 246•23 years ago
|
||
*** Bug 115356 has been marked as a duplicate of this bug. ***
Comment 247•23 years ago
|
||
*** Bug 150293 has been marked as a duplicate of this bug. ***
Comment 248•23 years ago
|
||
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.
Comment 249•23 years ago
|
||
*** Bug 150545 has been marked as a duplicate of this bug. ***
Comment 250•23 years ago
|
||
*** Bug 150557 has been marked as a duplicate of this bug. ***
Comment 251•23 years ago
|
||
*** Bug 150570 has been marked as a duplicate of this bug. ***
Comment 252•23 years ago
|
||
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!)
Comment 253•23 years ago
|
||
*** Bug 150585 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 254•23 years ago
|
||
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"
Comment 255•23 years ago
|
||
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.
Comment 256•23 years ago
|
||
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
Comment 257•23 years ago
|
||
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.
Updated•23 years ago
|
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!)
Comment 258•23 years ago
|
||
raising impact.
Comment 259•23 years ago
|
||
*** Bug 137486 has been marked as a duplicate of this bug. ***
Comment 260•23 years ago
|
||
*** Bug 150904 has been marked as a duplicate of this bug. ***
Comment 261•23 years ago
|
||
*** Bug 150896 has been marked as a duplicate of this bug. ***
Comment 262•23 years ago
|
||
*** Bug 150954 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
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!)
Comment 263•23 years ago
|
||
*** Bug 151679 has been marked as a duplicate of this bug. ***
Comment 264•23 years ago
|
||
*** Bug 152237 has been marked as a duplicate of this bug. ***
Comment 265•23 years ago
|
||
*** Bug 152321 has been marked as a duplicate of this bug. ***
Comment 266•23 years ago
|
||
*** Bug 145567 has been marked as a duplicate of this bug. ***
Comment 267•23 years ago
|
||
*** Bug 140413 has been marked as a duplicate of this bug. ***
Comment 268•23 years ago
|
||
*** Bug 141675 has been marked as a duplicate of this bug. ***
Comment 269•23 years ago
|
||
*** Bug 152466 has been marked as a duplicate of this bug. ***
Comment 270•23 years ago
|
||
Chris, do you have a new ETA for this?
Assignee | ||
Comment 271•23 years ago
|
||
just need to get reviews and land
Assignee | ||
Comment 272•23 years ago
|
||
Attachment #73116 -
Attachment is obsolete: true
Updated•23 years ago
|
Attachment #88236 -
Flags: superreview+
Comment 273•23 years ago
|
||
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 274•23 years ago
|
||
Comment on attachment 88236 [details] [diff] [review]
fixed spacing in the patch
r=bryner
Attachment #88236 -
Flags: review+
Comment 275•23 years ago
|
||
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.
Comment 276•23 years ago
|
||
*** Bug 148202 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 277•23 years ago
|
||
patch in trunk for win32 (the only platform it addressed)
Comment 278•23 years ago
|
||
paul - sujay is out on vacation. who can verify this fix tomorrow?
Comment 279•23 years ago
|
||
i'll check this out with tomorrow's trunk bits on win2k...
QA Contact: sujay → sairuh
Comment 280•23 years ago
|
||
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!)
Comment 281•23 years ago
|
||
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.
Comment 282•23 years ago
|
||
> ---- 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.
Comment 283•23 years ago
|
||
Could some of the reported problems here and in the dups be due to bug 103197?
Comment 284•23 years ago
|
||
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
Comment 285•23 years ago
|
||
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.
Comment 286•23 years ago
|
||
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.
Assignee | ||
Comment 287•23 years ago
|
||
definitely break this apart based on platform. There is a totoally different fix
for OSX for example, and I suspect the same for linux.
Comment 288•23 years ago
|
||
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.
Comment 289•23 years ago
|
||
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!)
Comment 290•23 years ago
|
||
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
Comment 291•23 years ago
|
||
*** Bug 151976 has been marked as a duplicate of this bug. ***
Comment 292•23 years ago
|
||
*** Bug 153631 has been marked as a duplicate of this bug. ***
Comment 293•23 years ago
|
||
So, could you (saari, jamie or sairuh) please file the appropriate bugs for the
other platforms, then, if you want to close this one?
Comment 294•23 years ago
|
||
*** Bug 153730 has been marked as a duplicate of this bug. ***
Comment 295•23 years ago
|
||
*** Bug 154118 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Attachment #88236 -
Flags: approval+
Comment 296•23 years ago
|
||
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+
Updated•23 years ago
|
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!)
Comment 297•23 years ago
|
||
*** Bug 154372 has been marked as a duplicate of this bug. ***
Comment 298•23 years ago
|
||
Has the win32 patch been checked into the branch yet? If not, please check this in.
Comment 299•23 years ago
|
||
*** Bug 155074 has been marked as a duplicate of this bug. ***
Comment 300•23 years ago
|
||
*** Bug 155268 has been marked as a duplicate of this bug. ***
Comment 302•23 years ago
|
||
*** Bug 144581 has been marked as a duplicate of this bug. ***
Comment 303•23 years ago
|
||
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?
Comment 304•23 years ago
|
||
Has this bug been fixed in the 1.1a release?
Comment 305•23 years ago
|
||
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)
Comment 306•23 years ago
|
||
vrfy'd fixed on the branch using 2002.07.02.08-1.0 comm bits on win2k.
Keywords: fixed1.0.1 → verified1.0.1
Comment 307•23 years ago
|
||
*** Bug 155605 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Alias: caret
Comment 308•23 years ago
|
||
*** Bug 155669 has been marked as a duplicate of this bug. ***
Comment 309•23 years ago
|
||
*** Bug 155946 has been marked as a duplicate of this bug. ***
Comment 310•23 years ago
|
||
*** Bug 156076 has been marked as a duplicate of this bug. ***
Comment 311•23 years ago
|
||
*** Bug 156144 has been marked as a duplicate of this bug. ***
Comment 312•23 years ago
|
||
*** Bug 156295 has been marked as a duplicate of this bug. ***
Comment 313•23 years ago
|
||
*** Bug 157021 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 314•23 years ago
|
||
*** Bug 157086 has been marked as a duplicate of this bug. ***
Comment 315•23 years ago
|
||
*** Bug 157140 has been marked as a duplicate of this bug. ***
Comment 316•23 years ago
|
||
*** Bug 157194 has been marked as a duplicate of this bug. ***
Comment 317•23 years ago
|
||
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 → ---
Comment 318•23 years ago
|
||
*** Bug 156946 has been marked as a duplicate of this bug. ***
Comment 319•23 years ago
|
||
*** Bug 157259 has been marked as a duplicate of this bug. ***
Comment 320•23 years ago
|
||
*** Bug 157280 has been marked as a duplicate of this bug. ***
Comment 321•23 years ago
|
||
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.
Comment 322•23 years ago
|
||
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.
Comment 323•23 years ago
|
||
> 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
Comment 324•23 years ago
|
||
*** Bug 157352 has been marked as a duplicate of this bug. ***
Comment 325•23 years ago
|
||
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)
Comment 326•23 years ago
|
||
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..."
Comment 327•23 years ago
|
||
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.
Comment 328•23 years ago
|
||
*** Bug 157705 has been marked as a duplicate of this bug. ***
Comment 329•23 years ago
|
||
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.
Comment 330•23 years ago
|
||
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.
Comment 331•23 years ago
|
||
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.
Comment 332•23 years ago
|
||
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.
Comment 333•23 years ago
|
||
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.
Comment 334•23 years ago
|
||
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?
Comment 335•23 years ago
|
||
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.
Comment 336•23 years ago
|
||
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.
Comment 337•23 years ago
|
||
^^^^^^^^^^ 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]
Comment 338•23 years ago
|
||
*** Bug 158262 has been marked as a duplicate of this bug. ***
Comment 339•23 years ago
|
||
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
Comment 340•23 years ago
|
||
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.
Comment 341•22 years ago
|
||
*** Bug 159550 has been marked as a duplicate of this bug. ***
Comment 342•22 years ago
|
||
I can reproduce this easily - set the home page to "http://" and open the
browser. It does it at least 10% of the time.
Comment 343•22 years ago
|
||
Workaround: Open the "find in this page" box and close it again.
Comment 344•22 years ago
|
||
*** Bug 151415 has been marked as a duplicate of this bug. ***
Comment 345•22 years ago
|
||
*** Bug 159684 has been marked as a duplicate of this bug. ***
Comment 346•22 years ago
|
||
*** Bug 160138 has been marked as a duplicate of this bug. ***
Comment 347•22 years ago
|
||
*** Bug 160330 has been marked as a duplicate of this bug. ***
Comment 348•22 years ago
|
||
*** Bug 150722 has been marked as a duplicate of this bug. ***
Comment 349•22 years ago
|
||
*** Bug 156331 has been marked as a duplicate of this bug. ***
Comment 350•22 years ago
|
||
*** Bug 161280 has been marked as a duplicate of this bug. ***
Comment 351•22 years ago
|
||
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
Assignee | ||
Comment 352•22 years ago
|
||
I was under the impression that I'd fixed all the quicklaunch cases. Did you see
that with a recent build?
Comment 353•22 years ago
|
||
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?
Reporter | ||
Comment 354•22 years ago
|
||
*** Bug 161895 has been marked as a duplicate of this bug. ***
Comment 355•22 years ago
|
||
*** Bug 163758 has been marked as a duplicate of this bug. ***
Comment 356•22 years ago
|
||
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)
Reporter | ||
Comment 357•22 years ago
|
||
*** Bug 164542 has been marked as a duplicate of this bug. ***
Comment 358•22 years ago
|
||
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.
Comment 359•22 years ago
|
||
*** Bug 116770 has been marked as a duplicate of this bug. ***
Comment 360•22 years ago
|
||
*** Bug 166154 has been marked as a duplicate of this bug. ***
Comment 361•22 years ago
|
||
For me this is gone with Mozilla 1.1 - 20020826 (using Win2K). Testcase from
comment 105 works too.
Comment 362•22 years ago
|
||
Platform Mac OS X - only bug now (bug 166154) ?
Comment 363•22 years ago
|
||
I still noticed this on W2K and XP, thou not nearly as often as it originally was.
Comment 364•22 years ago
|
||
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 365•22 years ago
|
||
Comment to Comment #364:
Doesn't work on my machine.
Mozilla 1.1, W2k SP3
Comment 366•22 years ago
|
||
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.
Comment 367•22 years ago
|
||
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)
Comment 368•22 years ago
|
||
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.
Comment 369•22 years ago
|
||
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
Comment 370•22 years ago
|
||
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
Comment 371•22 years ago
|
||
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.
Comment 372•22 years ago
|
||
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.
Comment 373•22 years ago
|
||
*** Bug 165141 has been marked as a duplicate of this bug. ***
Comment 374•22 years ago
|
||
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
Updated•22 years ago
|
Keywords: mozilla1.2,
mozilla1.3
Comment 375•22 years ago
|
||
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
Comment 376•22 years ago
|
||
*** Bug 181793 has been marked as a duplicate of this bug. ***
Comment 377•22 years ago
|
||
*** Bug 146047 has been marked as a duplicate of this bug. ***
Comment 378•22 years ago
|
||
*** Bug 183166 has been marked as a duplicate of this bug. ***
Comment 379•22 years ago
|
||
*** Bug 169671 has been marked as a duplicate of this bug. ***
Comment 380•22 years ago
|
||
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.
Comment 381•22 years ago
|
||
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.
Reporter | ||
Comment 382•22 years ago
|
||
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.
Comment 383•22 years ago
|
||
removed me from CC because of incessantly (useless?) comments though Comment #372
Comment 384•22 years ago
|
||
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
Assignee | ||
Comment 385•22 years ago
|
||
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)
Comment 386•22 years ago
|
||
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.
Comment 387•22 years ago
|
||
I've been seeing this a lot on recent (past ~2 weeks) Phoenix nightly builds on
WinXP, even on a clean install.
Comment 388•22 years ago
|
||
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).
Comment 389•22 years ago
|
||
*** Bug 184026 has been marked as a duplicate of this bug. ***
Comment 390•22 years ago
|
||
When I try to type an address in the bar mozilla closes as soon as i hit enter.
Comment 391•22 years ago
|
||
When I try to type an address in the bar mozilla closes as soon as i hit enter.
Comment 392•22 years ago
|
||
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.
Comment 393•22 years ago
|
||
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.
Comment 394•22 years ago
|
||
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.
Comment 395•22 years ago
|
||
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.
Comment 396•22 years ago
|
||
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).
Comment 397•22 years ago
|
||
*** Bug 150331 has been marked as a duplicate of this bug. ***
Comment 398•22 years ago
|
||
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.
Reporter | ||
Comment 399•22 years ago
|
||
"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
Comment 400•22 years ago
|
||
-> Verified as per reporter. Any further work in this bug is now impossible due
to its size.
Status: RESOLVED → VERIFIED
Comment 401•22 years ago
|
||
I think this is fixed also. I have not had the problem for a long time.
Comment 402•22 years ago
|
||
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
Reporter | ||
Comment 403•22 years ago
|
||
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.
Comment 404•22 years ago
|
||
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 ...
Comment 405•22 years ago
|
||
<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>
Comment 406•22 years ago
|
||
*** Bug 154128 has been marked as a duplicate of this bug. ***
Comment 407•22 years ago
|
||
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.
Reporter | ||
Comment 408•22 years ago
|
||
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.
Comment 409•22 years ago
|
||
*** Bug 169845 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Alias: caret
You need to log in
before you can comment on or make changes to this bug.
Description
•