Red Hat Bugzilla – Bug 4199
Netscape - Red Hat
Last modified: 2008-05-01 11:37:51 EDT
If I select an option from a drop down menu from the second list and onwards, the browser loses the ability to tye into text fields. This can be resolved by minimising the browser and then maximising or by clearing the cache in the preferences ( the cache is set to zero 0). The version of Netscape is v4.6, the version of Red Hat is v6. Is there a solution for this problem. regards Allan Irvine
Can't reproduce this here. No matter what menu options I select, I can still click on form field and fill them out...
What window manager are you using?
Here is some additional information. Hope it is helpful. (Note: this may be the same as bug 3586.) I have been trying to find a reproducible case to send to you, but it seems elusive. The problem seems to come and go, with the frequency varying with machine, even with similar configurations. The simplest test is for google.com. Here is my procedure: 1) Go to google.com 2) Press 'I'm feeling lucky button' (don't put anything in search field) 3) Pull dowm '10 results' menu, but leave at 10 4) See if text can still be typed in search field Let me describe my experience with 4 machines: Machine 1 (home computer) Bug occurs frequently, often when my wife is entering item for bid with eBay (very bad for my linux@home project ;) ) always seems to occur after using pulldown menu - can no longer type text in fields Hardware: i586 166MHz, 48 MB, IDE disks Software: RH6.0, Gnome+E updated to latest frome ftp.gnome.org, netscape 4.51 (downgraded from 4.6 in attempt to fix problem, no luck) Machine (Work Desktop) Bug has only occured once, despite many attempts Hardware: i586, 200MHz, 64MB, SCSI disks Software: RH6.0, gnome+E upgraded to latest ftp.gnome.org and some of Kelson's rpms, but not quite the latest, netscape 6.0 Machine 3 Bug often appears. Could reproducibly make happen with simple test above last friday morning, but effect went away in the afternoon. Hardware: i686, 266HHz, 128MB, ide disks Software: RH5.2, fvwm2, netscape 4.05 Machine 4 (Colleague's Desktop Computer) Bug occurs frequently, but Simple Test tried this morning for first time didn't make it happen. Hardware: i686, 300MHz, 96MB, ide disks Software: RH6.0, gnome+e (stock from RH6.0 CD), netscape 4.51 I also work with 2 other RH6.0 machines (one is a laptop) that haven't shown this problem, but I haven't tried very hard. I'm willing to provide more info and perform suggested tests, if that is useful. Good luck with this one guys, it really seems elusive.
OK, I've finally seen netscape hang again, though this time I wasn't using a pulldown menu, so maybe not the same. No response, doesn't repaint. This is machine #2, described above, which rarely has this problem. top gives for this process PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 6731 wilburn 11 0 24968 22M 5864 R 0 94.8 36.7 8:56 netscape-commun ps axl gives F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 100 0 1 0 0 0 1096 52 do_sel S ? 0:05 init [5] 040 0 2 1 0 0 0 0 bdflus SW ? 0:14 [kflushd] 040 0 3 1 0 0 0 0 kpiod SW ? 0:00 [kpiod] 040 0 4 1 0 0 0 0 kswapd SW ? 0:08 [kswapd] 040 0 5 1 -20 -20 0 0 md_thr SW< ? 0:00 [mdrecovery 040 0 6 1 -20 -20 0 0 md_thr SW< ? 0:00 [raid1d] 040 0 7 1 -20 -20 0 0 md_thr SW< ? 0:00 [raid1d] 140 0 351 1 0 0 1276 160 do_sel S ? 0:03 syslogd -m 140 0 362 1 0 0 1316 0 do_sys SW ? 0:00 [klogd] 040 2 376 1 0 0 1112 104 nanosl S ? 0:00 /usr/sbin/a 040 0 390 1 0 0 1284 112 nanosl S ? 0:00 crond 140 0 404 1 0 0 1568 60 do_sel S ? 0:18 /usr/local/ 140 0 417 1 0 0 1232 0 do_sel SW ? 0:00 [inetd] 140 0 431 1 0 0 1324 1324 do_sel SL ? 0:00 xntpd -A 140 0 446 1 0 0 1284 32 do_sel S ? 0:00 lpd 140 0 485 1 0 0 1884 328 do_sel S ? 0:03 sendmail: a 140 0 500 1 0 0 1112 56 nanosl S ? 0:00 gpm -t ps/2 040 100 515 1 0 0 5156 2532 do_sel S ? 9:32 xfs 100 0 533 1 0 0 1060 0 read_c SW tty1 0:00 [mingetty] 100 0 534 1 0 0 1060 0 read_c SW tty2 0:00 [mingetty] 100 0 535 1 0 0 1060 0 read_c SW tty3 0:00 [mingetty] 100 0 536 1 0 0 1060 0 read_c SW tty4 0:00 [mingetty] 100 0 537 1 0 0 1060 0 read_c SW tty5 0:00 [mingetty] 100 0 538 1 0 0 1060 0 read_c SW tty6 0:00 [mingetty] 100 0 539 1 0 0 2860 528 do_pol S ? 0:01 /etc/X11/pr 140 0 541 1 0 0 1052 36 nanosl S ? 0:06 update (bdf 100 0 6260 539 1 0 19636 11592 do_sel S ? 7:39 /usr/bin/X1 140 0 6270 539 0 0 3508 1420 wait4 S ? 0:00 /etc/X11/pr 100 501 6645 6270 0 0 1668 824 wait4 S ? 0:00 bash -login 000 501 6657 6645 0 0 1672 844 wait4 S ? 0:00 bash -login 040 501 6676 1 0 0 1476 356 do_sel S ? 0:00 /usr/local/ 000501 6677 6657 0 0 4932 708 do_pol S ? 0:00 gnome-sessi 000 501 6681 1 0 0 5144 1456 do_sel S ? 0:02 gnome-smpro 000 501 6685 1 0 0 3752 1420 do_sel S ? 0:25 [enlightenm 000 501 6700 1 0 0 2756 1512 do_sel S ? 0:04 xscreensave 000 501 6703 1 0 0 6012 2168 do_pol S ? 0:03 panel --sm- 000 501 6707 1 0 0 6804 1688 do_pol S ? 0:00 gmc --sm-co 000 501 6711 1 0 0 2456 1184 do_pol S ? 0:00 gnome-name- 000 501 6721 1 0 0 5376 676 do_pol S ? 0:00 gen_util_ap 000 501 6724 1 0 0 5416 876 do_pol S ? 0:10 gnomepager_ 000 501 6727 1 0 0 2836 1736 do_sel S ? 0:00 xterm -e /u 000 501 6729 6727 0 0 4084 1848 do_sel S pts/0 0:01 /usr/bin/pi 000 501 6731 1 16 0 35260 22372 - R ? 11:22 /usr/lib/ne 000 501 6741 6731 0 0 16724 320 do_sel S ? 0:00 [netscape-c 000 501 9103 1 0 0 2736 1616 do_sel S ? 0:00 /usr/X11R6/ 000 501 9143 1 0 0 5184 3056 do_pol S ? 0:01 gnome-termi 000 501 9144 9143 0 0 1288 556 unix_d S ? 0:00 gnome-pty-h 000 501 9145 9143 10 0 1972 1108 rt_sig S pts/1 0:00 -csh 000 501 9176 9145 18 0 2436 780 - R pts/1 0:00 ps axl note that the hung netscape has PID 6731 I'm not savvy enough to figure out any other diagnostics. Suggestions? I'll keep it running while I can. Scott
One additional clue. My wife reports that when this problem occurs, she is able to past text into a text field. This seems to then restore normal operation. Scott
This is a long time bug in Netscape. There is a work around -- if you minimize the netscape window and then bring it back again you will be able to put focus / type in a text field. This is the only known fix and as it has been reported to netscape by us before, I assume no other solution is forthcoming, unfortunately.